L4 7 Scripting API

Reference Manual
Scripting API for the

Layer 4-7 Application
January 2008
P/N 71-003808 REV A

Spirent Communications, Inc.
26750 Agoura Road
Calabasas, CA
91302 USA
Copyright
© 2008 Spirent Communications, Inc. All Rights Reserved.
All of the company names and/or brand names and/or product names referred to in this document, in particular, the
name “Spirent” and its logo device, are either registered trademarks or trademarks of Spirent plc and its subsidiaries,
pending registration in accordance with relevant national laws. All other registered trademarks or trademarks are the
property of their respective owners. The information contained in this document is subject to change without notice
and does not represent a commitment on the part of Spirent Communications. The information in this document is
believed to be accurate and reliable, however, Spirent Communications assumes no responsibility or liability for any
errors or inaccuracies that may appear in the document.
Limited Warranty
Spirent Communications, Inc. (“Spirent”) warrants that its Products will conform to the description on the face of
order, that it will convey good title thereto, and that the Product will be delivered free from any lawful security interest
or other lien or encumbrance.
Spirent further warrants to Customer that hardware which it supplies and the tangible media on which it supplies
software will be free from significant defects in materials and workmanship for a period of twelve (12) months, except
as otherwise noted, from the date of delivery (the “Hardware Warranty Period”), under normal use and conditions.
To the extent the Product is or contains software (“Software”), Spirent also warrants that, if properly used by Customer
in accordance with the Software License Agreement, the Software which it supplies will operate in material
conformity with the specifications supplied by Spirent for such Software for a period of ninety (90) days from the date
of delivery (the “Software Warranty Period”). The “Product Warranty Period” shall mean the Hardware Warranty
Period or the Software Warranty Period, as applicable. Spirent does not warrant that the functions contained in the
Software will meet a specific requirement or that the operation will be uninterrupted or error free. Spirent shall have no
warranty obligations whatsoever with respect to any Software which has been modified in any manner by Customer or
any third party.
Defective Products and Software under warranty shall be, at Spirent's discretion, repaired or replaced or a credit issued
to Customer's account for an amount equal to the price paid for such Product provided that: (a) such Product is
returned to Spirent after first obtaining a return authorization number and shipping instructions, freight prepaid, to
Spirent's location in the United States; (b) Customer provides a written explanation of the defect or Software failure
claimed by Customer; and (c) the claimed defect actually exists and was not caused by neglect, accident, misuse,
improper installation, improper repair, fire, flood, lightning, power surges, earthquake, or alteration. Spirent will ship
repaired Products to Customer, freight prepaid, based on reasonable best efforts after the receipt of defective Products.
Except as otherwise stated, any claim on account of defective materials or for any other cause whatsoever will
conclusively be deemed waived by Customer unless written notice thereof is given to Spirent within the Warranty
Period. Spirent reserves the right to change the warranty and service policy set forth above at any time, after
reasonable notice and without liability to Customer.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, ALL IMPLIED WARRANTIES, INCLUDING BUT
NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS
FOR A PARTICULAR PURPOSE, ARE HEREBY EXCLUDED, AND THE LIABILITY OF SPIRENT, IF ANY,
FOR DAMAGE RELATING TO ANY ALLEGEDLY DEFECTIVE PRODUCT SHALL BE LIMITED TO THE
ACTUAL PRICE PAID BY THE CUSTOMER FOR SUCH PRODUCT. THE PROVISIONS SET FORTH ABOVE
STATE SPIRENT'S ENTIRE RESPONSIBILITY AND CUSTOMER'S SOLE AND EXCLUSIVE REMEDY WITH
RESPECT TO ANY BREACH OF ANY WARRANTY.
Contents
About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hardware Handling/Cleaning Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
How to Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Scripting API Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Installing Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Installing the Scripting API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
On Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
On Linux or Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Upgrading Appliance Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Sample Test Configuration Arrays and Test Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Generate Tcl Scripts from the Layer 4-7 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Setting a Custom Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Checksum in Sample Configuration Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 2: Using the Scripting API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Configuring Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Modifying a Test Configuration Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Modifying a Sample Test Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Executing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Monitoring Results on the Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Validating Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Printing and Collecting Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Printing Results to a Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Debugging a Test Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapter 3: Test Configuration Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Format of a Profile Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Client Test Configuration Array Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Server Test Configuration Array Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Clustered Test Configuration Array Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Test Profile Interface Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Global Test Configuration Array Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Scripting API for the Layer 4-7 Application Reference Manual | 3

Contents
Chapter 4: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Clustered Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
General Terminology for Clustered Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Query Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Spirent TestCenter Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Appliance Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Standard Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Interactive Testing Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Appendix A: Statistics Message Indices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Client Statistics Message Indices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Filters to Use for Client Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
TCP Capture-Replay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
UDP Capture-Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
DDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Load Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Simulated Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
TCPState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
MM4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Server Statistics Message Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Filters to Use for Server Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
TCP Capture-Replay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
UDP Capture-Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
4 | Scripting API for the Layer 4-7 Application Reference Manual

Contents
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
TCP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
TCP State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
MM4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Appendix B: Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Sample Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Sample Test Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Appendix C: Troubleshooting Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Troubleshooting Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Check your environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Check your debug logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Check the autopath, license directory, and LD_LIBRARY_PATH . . . . . . . . . . . . . . . . 291
Check Spirent TestCenter provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Appendix D: ESD Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

General Equipment Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Workstation Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Appendix E: Fiber Optic Cleaning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Cleaning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

About this Guide
In About this Guide...
• Introduction . . . . 8
• Notation Conventions . . . . 8
• Related Documentation . . . . 9
• Hardware Handling/Cleaning Practices . . . . 10
• How to Contact Us . . . . 11

About this Guide
Introduction
Introduction
This reference manual provides detailed information on the Tcl scripting API you can use
to generate simulated, realistic Internet conditions and load. The Tcl API commands make
it easy to configure and run scripting tests from your command interface.
This manual is for users running Layer 4-7 tests on Spirent TestCenter ports within a
Spirent TestCenter chassis, as well as Avalanche appliances. These users include:
• Network equipment manufacturers (NEMs) and service providers who need to test
multi-function devices such as firewalls, VPN, routing, and web switching.
• IT professionals testing large enterprise networks and Web infrastructures.
It is assumed that users of this guide are familiar with Microsoft Windows® and Spirent
TestCenter, or appliance equipment, and have an intermediate knowledge of data
communications theory. Familiarity with Avalanche™ 6.5 or higher software and/or
ActiveState ActiveTcl™ software is preferred, but not required. Please see the Release
Notes for the ActiveTcl version to use for this release.
Notation Conventions
The following notational conventions are used throughout this manual:
Notation Example Meaning and Use
Courier typeface WaTestProfile Indicates elements such as names of parameters,

functions, files, and directories.
Angle brackets <interface> Indicates a user variable. Replace the text enclosed in
the angle brackets with an appropriate user-specified
item. Do not enter the brackets.
Square brackets [description] Indicates an optional parameter. Do not enter the

brackets.
Curly brackets {<attackname1> Indicates a Tcl list.

<attackname2>}
Vertical bar None | PAP | CHAP Separates items in a list. You must choose only one
item.
Ellipsis dots <Name>... Indicates that the item preceding the dots can be
repeated.
Backslash \ Indicates that the command continues to the next line.
Blue text See the AbortTest Indicates a cross-reference. You can click on the
function for more cross-reference to jump to the description of that
information. function or parameter.

About this Guide
Related Documentation
Related Documentation
See the following documents for information about products that work with the Layer 4-7
Tcl scripting API:
• Spirent TestCenter Layer 4-7 Application Quick Start Guide - Provides a summary of
the major steps you use to set up and run an HTTP-based Quick test on a Spirent
TestCenter chassis using the Layer 4-7 Application.
• Avalanche Commander Quick Start Guide - Provides a summary of the major steps
you use to set up and run an HTTP-based Quick test on one Avalanche client
appliance and one Avalanche server appliance using Avalanche Commander.
• Avalanche Analyzer online Help - Describes the Avalanche Analyzer user interface,
which allows you to view test result files generated by the Layer 4-7 Application.
• Avalanche URL Trace Tool online Help - Describes the Avalanche URL Trace Tool
user interface, which allows you to view URL Trace file results generated by the
Layer 4-7 Application.
• Avalanche Installation Guide - Provides installation instructions for the Avalanche
appliance hardware and software.
• Getting Started with Spirent TestCenter - Provides details on how to install Spirent
TestCenter chassis and modules and how to obtain license keys. Information is also
provided on module LEDs, multiple chassis connections, cables, and chassis
commands.
• Layer 4-7 Application online help – Provides information on all procedures required
to prepare your testing environment for running tests on a Spirent TestCenter chassis,
and Avalanche appliances.
• Spirent TestCenter System Reference Manual - Provides application overview
information, and directs you to appropriate sources for the latest detailed product
descriptions.
Note: The Layer 4-7 documentation is located in your installation’s documentation

directory. This document is located in your TclAPI installation “Documentation”
directory. The Spirent TestCenter documentation is available with your product’s
installation.

About this Guide
Hardware Handling/Cleaning Practices
Hardware Handling/Cleaning Practices

Spirent Communications’ cards and modules contain electronic components that are
sensitive to Electrostatic Discharge (ESD) damage. To prevent premature component
failure or latent product damage, it is crucial that you handle this equipment following
industry standard ESD handling practices. Refer to Appendix D, “ESD Requirements” for
further information.
Some equipment contains fiber optic components that are very susceptible to
contamination from particles of dirt and dust. Product performance may be damaged if
these components are not kept clean. Refer to Appendix E, “Fiber Optic Cleaning
Guidelines” for proper cleaning practices for these components.

About this Guide
How to Contact Us
How to Contact Us
To obtain technical support for any Spirent Communications product, please contact our
Support Services department using any of the following methods:
Americas
E-mail: [email protected]
Web: http://support.spirentcom.com
Toll Free: +1 800-SPIRENT (+1 800-774-7368) (US and Canada)
Phone: +1 818-676-2616
Fax: +1 818-880-9154
Hours: Monday through Friday, 05:30 to 16:30, Pacific Time
Europe, Africa, Middle East

Web: http://support.spirentcom.com
Phone: +33 (0) 1 61 37 22 70
Fax: +33 (0) 1 61 37 22 51
Hours: Monday through Thursday, 09:00 to 18:00, Friday, 09:00 to 17:00, Paris Time
Asia Pacific
Web: http://support.spirentcom.com.cn
Phone: 400 810 9529 (mainland China)
Phone: +86 400 810 9529 (outside China)
Fax: +86 10 8233 0022
Hours: Monday through Friday, 09:00 to 18:00, Beijing Time
The latest versions of user manuals, application notes, and software and firmware updates
are available on the Spirent Communications Customer Service Center websites at
http://support.spirentcom.com and http://support.spirentcom.com.cn (China).
Information about Spirent Communications and its products and services can be found on
the main company websites at http://www.spirentcom.com and
http://www.spirentcom.com.cn (China).
Company Address
Spirent Communications, Inc.
26750 Agoura Road
Calabasas, CA 91302
USA

Chapter 1
Introduction
This chapter introduces the Scripting API for the Layer 4-7 Application Reference
Manual, provides a list of the system and PC requirements necessary to run this software,
and describes how you get started.
In this chapter...
• Scripting API Overview . . . . 14
• Installing Java . . . . 14
• Installing the Scripting API . . . . 15
• Supported Configurations . . . . 17
• Upgrading Appliance Software . . . . 18
• Getting Started . . . . 20
• Sample Test Configuration Arrays and Test Scripts . . . . 21

Chapter 1: Introduction
Scripting API Overview
Scripting API Overview

The Scripting API for the Layer 4-7 Application is a Tcl-based API that provides the same
functionality you have with the Layer 4-7 Application: you can create and run tests on
appliances and Spirent TestCenter ports within a Spirent TestCenter chassis. Use the Tcl
commands described in this manual to create a user-specific test script. Consult a standard
Tcl reference document for general Tcl information.
For the correct version of the ActiveState Active Tcl to use, please see the Release Notes.
If you do not have the required version, you can download the version for your platform
from one of the following ftp sites:
ftp://ftp.activestate.com/ActiveTcl/Linux/
ftp://ftp.activestate.com/ActiveTcl/Solaris/
ftp://ftp.activestate.com/ActiveTcl/Windows/
When you run a test, your script controls the starting and stopping of clients and servers.
You do not need to be present to run tests or collect results.
Please see the Release Notes for information about system requirements, cable
requirements, PC requirements, and network connectivity.
Installing Java
Note: The Layer 4-7 Application includes Java when installed in a Windows
environment. Therefore, you do not need to install Java, if you plan to run a Layer 4-7 test
in a Windows environment. You need to install Java only if you plan to run a Layer 4-7
test in a Unix (Linux/Solaris) environment.
To install Java:
1 Install Java 2 Platform, Standard Edition, version 1.5 (J2SE) on your Linux or Solaris
host, if it is not already installed. You can download it from http://java.sun.com/jav-
ase/downloads/index_jdk5.jsp. Both version numbers “1.5” and “5.0” identify the
release of the Java 2 Platform Standard Edition. (Version “5.0” is the product version,
while “1.5.0” is the developer version.)
2 After you have installed Java 1.5, if you are using Solaris or Linux, and there is no
Java executable path already defined in the PATH environment variable, then you
must set either the PATH or JAVA_HOME environment variable. (If you set both,
then the PATH will take precedence.)
Examples:
csh: setenv JAVA_HOME “<Java_Install_Dir>”
sh: JAVA_HOME =“<Java_Install_Dir>” export JAVA_HOME
bash: export JAVA_HOME=“<Java_Install_Dir>”

Installing the Scripting API
Notes: • On Linux and Solaris platforms, you must add the Java executable path into
either the PATH or JAVA_HOME environment variable for the result files to
be merged seamlessly. If one of these environment variables is not set
correctly, the following error will appear at the end of a test run during the
result files merge time:
Transferring Client Cluster ResultsERROR: Error invoking merge:
couldn't execute "java": no such file or directory
• On Windows machines, you do not need to set the JAVA_HOME or PATH
environment variable.

You use the Scripting API for the Layer 4-7 Application to establish a connection and
configure your appliances or Spirent TestCenter cards. For Linux and Solaris systems, the
Scripting API software can be downloaded from the Spirent Communications Customer
Service Center website at http://support.spirentcom.com or copied from the CD shipped
with your order.
The Scripting API software for Windows XP SP2 is automatically installed when you
install the Layer 4-7 Application. See the Release Notes for step-by-step instructions on
installing the Scripting API for the Layer 4-7 Application.
On Windows
To Install the Scripting API Software on Windows XP
Run the Layer 4-7 Application installation program on your Windows XP PC, and follow
the instructions in the InstallShield Wizard.
Note: When you uninstall the software (via Add/Remove Programs on your PC),
additional files may be left in the installation directory. The uninstaller only removes those
files explicitly installed by the installer, and does not remove any additional files or
directories created after installation.
On Linux or Solaris
To Install the Scripting API Software on Linux or Solaris
Be sure to read the Release Notes for important installation, configuration, and test
guidelines that may have been updated since this document was written. This section of
the documentation covers important information for successfully installing the Scripting
API software on Linux or Solaris machines. Also, read the Release Notes for additional
information about installing the Tcl API on Linux and Solaris machines.

The Scripting API for the Layer 4-7 Application for Solaris and Linux is delivered as a
tarball archive.
Note: The following programs must be installed on your system, and the path of their
executables should be set in your PATH: Java 1.5, tar, gunzip, and ActiveTcl. Refer to the
Release Notes for the correct version of ActiveTcl to use for the current release.
1 Transfer the tarball (.tgz file) to your Linux/Solaris host.
Note: Tcl API functionality is dependent on the tar and gzip commands. The Tcl API
does not call these two commands with their absolute paths; their location is assumed
to be part of the user's PATH environment variable. If that is not the case, then you
will get an error message such as ‘tar –cf test.tar .: Command not found.’
If “tar” and “gzip” commands are not part of your PATH environment variable by
default, add their locations into your PATH environment variable. You can check if
the path to “tar” and “gzip” commands is in your PATH variable by using the “which
tar” and "which gzip" commands. If they are already in your PATH variable, then the
full path/location for these commands will be successfully returned.
2 Unzip the tarball file to extract its contents. The following example is for a Solaris tar-
ball:
gunzip Spirent_TestCenter_Auto_Solaris_2.xx.tar.gz
3 Untar the unzipped tarball. At this point, the tarball will only have a “.tar” extension.
The following example untars the Solaris tarball:
tar -xvf Spirent_TestCenter_Auto_Solaris_2.xx.tar
4 The following directory structure is then created in your current directory:
<current_dir>
|_ Spirent_TestCenter_2.xx
|_ Layer_4_7_Application_Solaris
|_ STC
|_ TclAPI
5 Define your appropriate environment variables as follows:
bash example:
export LD_LIBRARY_PATH=“/<current_dir>/Spirent_
TestCenter_2.xx/Layer_4_7_Application_Solaris/STC:/
<current_dir>/Spirent_TestCenter_2.xx/
Layer_4_7_Application_Solaris/TclAPI/SmartLib/unix/
solaris:$LD_LIBRARY_PATH”
Note: If you plan to generate a portable Tcl test from the Layer 4-7 Application (for
example, you many want to generate a test in Windows, and then execute it on another
operating system or computer), then you must set the following additional system
environment variable on every computer on which you intend to run the test:
SPIRENT_TCLAPI_ROOT
SPIRENT_TCLAPI_LICENSEROOT (only needed for appliances)

Supported Configurations
The first variable should point to the root API installation directory on the computer. The
second variable should point to a directory housing the correct TclAPI license(s)
(appliances only) on that computer. If these two variables have been configured correctly,
and a valid license file exists within the license directory (appliances only), the test should
run successfully. If you do not want to set these environment variables on your computer,
you can manually modify the test script to include these variables.
bash:
export SPIRENT_TCLAPI_ROOT=”<current_dir>/
Spirent_TestCenter_2.xx/Layer_4_7_Application_Solaris/
TclAPI”
Supported Configurations
This section provides a brief overview of the various capabilities of the scripting API.
Current Supported Functionality

The API supports the following features:
• Creation and manipulation of Client Load, Network, Interface, Subnet, and User
profiles
• Creation and manipulation of Server Network, Interface, Subnet, Server, and
Transaction profiles
• Ability to create, start, and stop a test
• Ability to retrieve results from a test.

Upgrading Appliance Software

To install the latest product software on Client or Server appliances, if you are using a
Windows system, use the Software Upgrade button in Avalanche Commander (the Layer
4-7 Application GUI). (See “Upgrading Appliance Software” in the Layer 4-7 Application
online help for more information.)
Because Avalanche Commander is not available for Solaris or Linux systems, if you are
using the Tcl API on a Solaris or Linux system, you must use the following steps to
upgrade your Avalanche appliance (2500, 250, or 2700) with Avalanche Commander:
To upgrade appliance software
1 Open a console window in your Linux or Solaris host machine.

2 Transfer the avalanche_<version>.tgz file to your host.
3 Go to the directory in which the .tgz file now resides, for example: cd /var/ftp/
TGZ/
4 FTP to the IP address of the appliance, for example: ftp 10.20.30.40.
5 Type root for your login ID, and welcome for your password. These are the default
credentials for the appliance.
6 Go to the /disk/images directory: cd /disk/images.
7 Upload the avalanche binary file to /disk/images and exit:
put avalanche_<version>.tgz
bye
Note: For the 2700 appliance, you must use the .tgz file with “-lx” in its name.
8 Telnet to the IP address of the appliance using the same login ID and password as
before:
telnet 10.20.30.40
login: root
password: welcome
9 If you are upgrading the 2700 appliance, run /swat/bin/upgradeswat. A menu appears
in which you must choose which version to install. Choose the Avalanche Com-
mander image that you previously uploaded. The Avalanche Commander process
automatically restarts.
Note: You may want to leave only the new.tgz file in the /disk/images directory and
move the old .tgz file into a repository type of directory before issuing a shutdown
command. This extra step helps to ensure that the appliance will reboot without any
problems.
10 If you are upgrading an appliance other than the 2700, reboot the system with
shutdown -f

The following example illustrates this process:

To FTP the Layer 4-7 Application software to the 2700 appliance:
ftp 10.20.30.40
login: root
password: welcome
cd /disk/images
bin
put avalanche-lx_<version>.tgz
bye
To upgrade the image currently in use:
telnet 10.20.30.40
login: root
password: welcome
/swat/bin/upgradeswat
<Choose the image you want to execute>
exit
To FTP the Layer 4-7 Application software to any appliance other than the 2700:
ftp 10.20.30.40
login: root
password: welcome
cd /disk/images
bin
put avalanche-lx_<version>.tgz
bye
To upgrade the image currently in use:
telnet 10.20.30.40
login: root
password: welcome
shutdown -f

Getting Started
Getting Started
Before you develop your own tests, it is a good idea to practice the basic steps you must
complete to configure and run a test. The following procedure summarizes the basic steps
you follow to run an existing sample test on your hardware. The Scripting API for the
Layer 4-7 Application includes sample test configuration arrays and test scripts.
To modify/configure and run an existing client/server test:
1 Check license and network information.

2 Select the hardware that you want to use with the test.
3 Configure the client and server in the test configuration file.
4 Create or modify one of the Tcl test scripts.
5 Run, validate, and monitor the test.
6 View and analyze test results.
For detailed information on checking license and network information and setting up the
hardware to use with your test, see the Layer 4-7 Application online help).
To configure and run a test on devices using the scripting API, you must first set up the
required test parameters in a test configuration array file. You use any text editor to
modify the parameters in a provided sample test configuration array file. At a minimum,
you must modify the provisioning entries for Spirent TestCenter ports.
Once you configure the test configuration array, you can modify the test script to run the
test. This script contains a call to the file containing the test configuration array you
modified. You must check to be sure that the following parameters in your test script are
correct and modify them if necessary:
• Path to the core API files (set auto_path <path> command)
• Path to the file containing the test configuration array (source <config_array>
command)
• IP address(es) of the client
• IP address(es) of the server
• Test name (testId variable definition)
• Test directory (testDirectory variable definition) that specifies the location of the
test configuration XML files that will be generated and uploaded onto the Spirent
TestCenter or appliance platform, and the result files that will be generated at the end
of the test run.
For more detailed instructions on modifying a test configuration array and test script, see
Chapter 2, “Using the Scripting API.”

Getting Started
Sample Test Configuration Arrays and Test Scripts

The Scripting API for the Layer 4-7 Application includes sample test configuration files
and test scripts that you can use to configure and run your tests. These sample files are
included in the SampleTests directory. The following directory contains the sample tests
for the Linux version:
/<TclAPI_installation_dir>/Spirent_TestCenter_2.xx/
Layer_4_7_Application_Linux/TclAPI/SampleTests
The sample tests in this directory have these caveats:
• They are designed to be run between client and server units when these systems are
connected through the same vlan on a switch.
• They run optimally on appliances with dual CPUs and GigEthernet connectivity. They
do not account for the complexities of various network topologies and should only be
used as an example for creating custom tests.
• They can be copied, but should not be modified, as they were designed to acquaint
customers with the product.
Generate Tcl Scripts from the Layer 4-7 Application

You can also generate Tcl test scripts from the tests you create in the Layer 4-7
Application. The resulting Tcl test files (a test configuration array and a Tcl test script) are
stored in the specified output directory. See Chapter 2, “Using the Scripting API” for
more information about creating and modifying test scripts. Also, see the Layer 4-7
Application online Help topic “Converting a Test to a Tcl Script” for more about
converting a test to a Tcl script.
Tip: If you get an error message when generating a Tcl script from a test created in the
Layer 4-7 Application, check the log files created in the GUI2TclDebug and TestDivide
directories to help you troubleshoot the issue: Gui2Tcl_out.log, Gui2Tcl_err.log,
Divide.err, and Divide.out.
Setting a Custom Username

In the Layer 4-7 Application, you can set a custom username by choosing Preferences
from the Tools menu, and then clicking on “User Name” under “Miscellaneous.” Select
the “Custom” radio button, and enter a new user name in the field next to the button.
To set a custom username in the Tcl API:
On a Windows platform, enter the following in the command prompt window in which the
Tcl script will run:
set username=<custom_username>

Getting Started
On a Unix (Linux/Solaris) platform, enter the following in the console window in which
the Tcl script will run:
export USER=<custom_username> (for bash shell)
This command changes the ownership information used by the Tcl API.
Tip: When you reserve port groups, you can see this username information in the
Layer 4-7 Application's Administration window for both appliances and Spirent
TestCenter while a Tcl API test is running (assuming you have a PC with the Layer 4-7
Application installed in your environment).
Checksum in Sample Configuration Arrays

Each sample script includes a checksum element within its corresponding configuration
array. The checksum is there so that we can easily determine if someone has modified the
configuration array. If the checksum is not valid, it does not prevent the test from running.
It is only there to help us determine whether a test script was modified after it was
generated from the Layer 4-7 Application. This helps us narrow where the problem is
when we get a problem script from a customer. You can manually remove the checksum
element without consequence.

Chapter 2
Using the Scripting API
This chapter explains how to use the Scripting API for the Layer 4-7 Application,
including how to modify a test configuration array, modify a test script, validate and
monitor test results, and debug a test. A test configuration array enables you to specify
exactly what you want to test and how you want to test it on the appliance or Spirent
TestCenter hardware. Any test you can create an run in the Layer 4 - 7 Application, you
can create and run using its Tcl scripting API.
In this chapter...
• Configuring Tests . . . . 24
• Executing Scripts . . . . 31
• Validating Scripts . . . . 36
• Printing and Collecting Test Results . . . . 37
• Debugging a Test Script . . . . 38

Chapter 2: Using the Scripting API
Configuring Tests
Configuring Tests
If you are using a Windows machine, we recommend that you use the “Generate Tcl Test”
feature in the Layer 4-7 Application to generate your Tcl scripts. The resulting Tcl test
files (a test configuration array and a Tcl test script) are stored in the specified output
directory. See the Layer 4-7 Application online Help topic “Converting a Test to a Tcl
Script” for more information.
If you are using a Solaris or Linux machine, we recommend that you start by copying and
then modifying one of the sample scripts packaged with your software. The Scripting API
for the Layer 4-7 Application includes several sample test configuration arrays and Tcl
test scripts.
Modifying a sample test involves two types of files:
• A file containing the test configuration array parameters (config.tcl)
• A Tcl script that sources the configuration array and runs the test (test.tcl)
Note: You can also create one file that contains both the configuration array and the test
script.
You can run the sample Tcl API scripts on one of the following platforms:
• Appliance
• Spirent TestCenter
The sample scripts are available in the Tcl API branch under the ../SampleTests
directory. Appendix B, “Sample Files” also contains a printout of the sample
configuration file for Spirent TestCenter (config.tcl)and its corresponding sample
test script (test.tcl). However, refer to the set of sample scripts packaged with the Tcl
API for the most recent API scripts.
To configure and run a client/server test:
1 Check license and network information.

2 Select the hardware to use with your test.
3 Create or modify the required test parameters in the test configuration file.
4 Create or modify a Tcl test script.
5 Run, validate, and monitor the test.
6 View and analyze test results.
Modifying a Test Configuration Array

A test configuration array is the central means by which the API generates the necessary
configuration file to upload into the Spirent TestCenter chassis or appliance. It contains
hardware information, such as device IP address and test name, to test specific
information such as network, interface, and load profile configurations.

Configuring Tests
The Scripting API for the Layer 4-7 Application includes sample test configuration array
files for you to run or modify. Select the one that most closely matches your Solaris or
Linux platform, copy it, and then modify its parameters. Because configuration files are
ASCII text files, you can use any text editor to edit them.
Open the ConnsPerSecApp config.tcl file in your SampleTests directory to see a typical
test configuration array for an appliance. Note the parameters are on the left, and the
values for those parameters are in curly braces {} on the right.
All of the appliance versions of the sample tests included with your software are designed
to run on two 2500 appliances; each 2500 has two units or processors.
Note: The term “unit” is used throughout this document to denote either of the following:
• CPU number of the unit for an appliance
• Spirent TestCenter port group number for a Spirent TestCenter chassis
Modifying a Test Configuration Array for an Appliance

Next, you will learn how to modify the Open Connections sample configuration array for
an appliance.
To modify a sample configuration array for your appliance:
1 Go to the /SampleTests directory where the sample files are stored.

2 Find the sample configuration script that most closely matches your hardware and the
kind of test you want to run. For example, to edit the Open Connections sample con-
figuration array for a 2500 appliance, go to /SampleTests/OpenConns/Appli-
anceVersion.
3 Copy the OpenConnsAppConfig.tcl file to your test directory and rename it to
something you will remember.
Note: You do not have to use the .tcl extension in the name of the test configuration
array file. For example, you could name it configAv2500OpenConn.txt.
4 Open the copy of your sample file that you just renamed.

Configuring Tests
5 Configure your test parameters and their values. Add and/or delete necessary sections
of the client profiles partially or as a whole in the configuration array.
If you plan to use the defaults, you do not need to modify most of the parameters.
Refer to Chapter 3, “Test Configuration Array” for an explanation of each parameter.
It contains a list of all parameters with their descriptions and default values.
However, you must modify the network address subnet that you want to represent for
your test ports, and enter the range of IP addresses from which you want to generate
traffic for your test ports in the following WaSubnet parameters:
WaSubnet,ConnsPerSec_sn0,IpAddressRanges,IpAddressRange \
{192.168.42.20-192.168.42.30}\
WaSubnet,ConnsPerSec_sn0,Network {192.168.42.0}\
6 Set the server profile parameters, starting with WrTestProfile,Description

{Advanced Generic Device Test}. Add and/or delete necessary sections of the
server profiles partially or as a whole in the configuration array.
your test ports, and enter the range of server IP addresses:
WrSubnet,echo_sn0,Network {192.168.42.0}\
WrSubnet,echo_sn0,ServerProfile,0,IpAddressRange {192.168.42.11}\
7 Save the changes to your modified configuration file.
Modifying a Test Configuration Array for a Spirent TestCenter Chassis

Next, you will learn how to modify the Open Connections sample configuration array for
a Spirent TestCenter chassis.
Spirent TestCenter cards are segregated into a number of port groups, each containing one
to two individual ports, depending on the model. Once provisioned, these port groups are
locked for use by you and flagged as “locked” to other users.
To modify a configuration array file for a Spirent TestCenter chassis:
1 Go to the /SampleTests/STC/AdvDevOpenConns directory.

2 Copy the config.tcl file to your test directory and rename it to something you
will remember.
Note: You do not have to use the .tcl extension in the name of the test configuration
array file. For example, you could name it configSTCopenConn.txt.
3 Open the copy of your sample file that you just renamed.

Configuring Tests
4 Define a provisioning list for each port. You enter the portID parameter in the follow-
ing format: <Chassis IP>:<Slot>,<Port>. You must provide all parameters
(port ID, MAC address, etc.) for each port and in the order shown in the script. The
order of parameter values is very important, so skipping a parameter value or chang-
ing the order of these values will give you error messages and prevent your test from
running. Your sample Spirent TestCenter configuration file includes a four-port provi-
sion list, which you can modify for your configuration.
# <PortID> <PortMAC> <PortMedia> <PortDuplex> <PortSpeed>\

# <PortAutoNeg>
#
lappend stcProvisionList [list "10.47.52.21:3,1" \
"a4-b4-89-00-00-19" "Copper" "Full" "100" "Enable"]

"a4-b4-89-00-00-1d" "Copper" "Full" "100" "Enable"]


5 You can add another port by defining a provisioning list for it. You must define a pro-
visioning list for each port you add. In the following script, we have added two ports
(shown in bold):


6 Configure your test parameters and their values. Add and/or delete necessary sections
of the client profiles partially or as a whole in the configuration array.
It contains a list of all parameters with their descriptions and default values.
your test ports, and enter the range of IP addresses from which you want to generate
traffic for your test ports in the following WaSubnet parameters:
WaSubnet,OpenConns_sn0,Network {192.168.42.0}
WaSubnet,OpenConns_sn1,IpAddressRanges,IpAddressRange
{192.168.42.65-192.168.42.126}
7 Set the server profile parameters, starting with WrTestProfile {test Description...}.
Add and/or delete necessary sections of the server profiles partially or as a whole in
the configuration array.

Configuring Tests
your test ports, and enter the range of server IP addresses:
WrSubnet,echo_sn0,Network {192.168.42.0}
WrSubnet,echo_sn0,ServerProfile,0,IpAddressRange {192.168.42.11}
8 Save the changes to your modified configuration file.
Modifying a Sample Test Script

After you have modified the configuration array for your test, you are ready to select and
edit one of the test scripts for your test.
You must modify the following parts of your test script:
• Path to the core API files (set auto_path <path> command)
• Path to the file containing the test configuration array (source <config_array>
command)
• IP address(es) of the client
• IP address(es) of the server
• Test name (testId variable definition)
• Test directory (testDirectory variable definition) that specifies the location of the
test configuration XML files that will be generated and uploaded onto the Spirent
TestCenter or appliance platform, and the result files that will be generated at the end
of the test run.
To modify a sample test script for an appliance:
1 Open the sample test.tcl script.

2 Define a callback procedure.
You may add new or delete existing statistics to be displayed in real-time on your
screen while running this script. See “RegisterStatsCallback” on page 216 and
Appendix A, “Statistics Message Indices” for more information about statistics.
3 Before using the Tcl API commands for the Layer 4-7 Application, you must set the
path to the Tcl API installation directory so the API can find the core package:
set auto_path [linsert $auto_path 0 "C:/Program Files/Spirent Com-

munications/Spirent TestCenter 2.xx/Layer 4-7 Application/TclAPI"]
4 Be sure not to change the package require command: package require SPI_AV

Configuring Tests
5 Be sure that the InitializeAPI function appears right after the package require
command so that the API is ready for use:
SPI_AV::InitializeAPI
6 Be sure that you associate an appropriate license file with the test. You can add more
licenses via additional calls to the SPI_AV::AddLicense function.
SPI_AV::AddLicense <license_file_location>
7 Modify the “source” command with the path to the file containing the test
configuration array to use for this test. For example:
source "./config.tcl"
8 Modify the testDirectory and testID variables in which the directory names/
locations where your XML configuration and results files are stored.
9 Save your script.
Remember to save the script with a different name so you do not overwrite the sample
script.
Note: Because they provide access to the API functions, you must always enter the set
auto path and package require commands at the beginning of a new Tcl test script.
To modify a sample test script for a Spirent TestCenter chassis:
1 Open the sample test.tcl script.

2 Define a callback procedure.
You may add new or delete existing statistics to be
displayed in real-time on your screen while running this script. See “Register-
StatsCallback” on page 216 and Appendix A, “Statistics Message Indices” for more
information about statistics.
3 Before using the Tcl API commands for the Layer 4-7 Application, you must set the
path to the Tcl API installation directory so the API can find the core package:

munications/Spirent TestCenter 2.xx/Layer 4-7 Application/TclAPI"]
4 Be sure not to change the package require command: package require SPI_AV
5 Be sure that the InitializeAPI function appears right after the package require
command so that the API is ready for use:
6 Be sure that you associate the correct chassis IP address(es) with the
SPI_AV::AddLicense function to generate a valid license file for the test.
SPI_AV::AddLicense -STC 10.47.70.40

Configuring Tests
You can have more than one chassis IP address in the SPI_AV::AddLicense function
call, if more than one chassis is involved in the test, using the following syntax:
SPI_AV::AddLicense -STC <ChassisIp> <ChassisIp2>...<ChassisIpN>
7 Modify the “source” command with the path to the file containing the test configura-
tion array to use for this test, for example:
source "./STC/AdvDevOpenConns/config.tcl"
8 Modify the testDirectory and testID variables in which the directory names/loca-
tions where your XML configuration and results files are stored.
9 Save your script.
Remember to save the script with a different name so you do not overwrite the sample
script.

Executing Scripts
Executing Scripts
Before running a test, make sure all the systems you intend to use (clients or servers) are
up and running. Spirent Communications recommends that, when creating a new test, you
start with a small load to verify the connectivity between clients and servers, and the
device or infrastructure under test.
Once connectivity has been established, you should start incrementally increasing the
amount of traffic generated until the desired load is achieved. The creation of a high load
on the first test, without first establishing connectivity, might lead to problems that are
easier to identify with a test with a small amount of traffic.
Note: We strongly recommend that you run your scripts in separate Tcl shells, instead of
running several tests or the same test several times in the same Tcl shell.
To run a test script:
1 Open a new window. If you are using Windows, choose Run from the Start menu,
enter cmd, and then click OK.
2 Change to the directory containing the script to run (for example, cd
TclAPI\Tests).
3 Run your Tcl script. For instance, enter tclsh test.tcl as shown in the
following example:
Figure 2-1. Running Your Script in Windows
While the script is running, messages appear on the screen displaying live statistics. When
the run has finished, you can view the test results in the .csv results files.
You can monitor a test while it is running by watching the real-time client and server
statistics messages that appear on the screen. You can also print the test results to a file.
To collect results, you must configure your script via a callback function.
Monitoring Results on the Screen

To check your real-time statistics while a test is running, you must define two callback
procedures: one for the client side to pass real-time client statistics and one for the server
side to pass real-time server statistics. These two procedures print out client and server
real-time statistics on the screen during a test run.

Executing Scripts
To register callbacks to check the real-time messages while a test is running:
1 Define client and server callback procedures that will pass the real-time statistics data
captured by the SPI_AV::ClusterController::RegisterStatsCallback func-
tions and display the results on the screen or print them to a log file. Because the data
is continuously updated in the array, you can see the progress of the test by looking at
the printed messages on the screen.
Example:
# Define a Client callback procedure
#
proc clientStatsCallbackProc {clusterID data} {
array set dataArray $data
catch {
puts "Client Attempted : $dataArray(http,attemptedTxns)"
puts "Client Successful : $dataArray(http,successfulTxns)"
puts "Client Unsuccessful : $dataArray(http,unsuccessfulTxns)"
puts "Client Aborted : $dataArray(http,abortedTxns)"
puts "\tTIME (seconds) Elapsed : $dataArray(timeElapsed)"
puts "\t\t\tRemaining : $dataArray(timeRemaining)"
}
puts ""
}
#
# Define a Server callback procedure
#
proc serverStatsCallbackProc {clusterID data} {
catch {
puts "Server Per second : $dataArray(tcpConn,connsPerSec)"
puts "Server Open : $dataArray(tcpConn,openConns)"
puts "Server Closed with error : $dataArray(tcpConn,closedWithEr-
ror)"
puts "Server Closed with reset : $dataArray(tcpConn,closedWith-
Reset)"

Executing Scripts
puts "Server Closed no error : $dataArray(tcpConn,closedWithNo-

Error)"
}
puts ""
}
2 For the "SPI_AV::ClusterController::RegisterStatsCallback" function,
specify the cluster ID of the client and the cluster ID of the server box or card, the
name of the user-defined procedures (clientStatsCallbackProc and server-
StatsCallbackProc), and a filter list (time, http, and tcpConn in this example)
that specifies the statistics you want to collect during a test run. The callback IDs are
saved in the variables named "clientStatsCallbackID" and “serverStatsCall-
backID” to be used later for unregistering when the test ends (see the example
below).
#
# Register a statsCallback for the cluster(s)
#
set clientStatsCallbackID
[SPI_AV::ClusterController::RegisterStatsCallback $clientClusterID
clientStatsCallbackProc [list "time*" "http"]]
set serverStatsCallbackID
[SPI_AV::ClusterController::RegisterStatsCallback $serverClusterID
serverStatsCallbackProc [list "tcpConn" "time*" ]]
#
# Unregister the previously registered callbacks
#
catch {SPI_AV::ClusterController::UnregisterStatsCallback
$clientClusterID $clientStatsCallbackID}
catch {SPI_AV::ClusterController::UnregisterStatsCallback
$serverClusterID $serverStatsCallbackID}
Here is an example of output displayed on the screen when a test with the above sample
code is run:
C:\TclAPI\2.xx\Build_0045\ModDefTrasaction>tclsh test.tcl
Attempting to provision Spirent TestCenter Ports
STC Port (10.47.20.21:1,1) provisioned SUCCESSFULLY

Executing Scripts

Spirent TestCenter Ports SUCCESSFULLY provisioned
Generating Test - done
Stopping Client Cluster - done
Stopping Server Cluster - done
Removing Test From Client Cluster - done
Removing Test From Server Cluster - done
Uploading Test To Client Cluster - done
Uploading Test To Server Cluster - done
Starting Server Cluster - done
Starting Client ClusterServer Per second : 0
Server Open : 0
Server Closed with error : 0
Server Closed with reset : 0
Server Closed no error : 0
TIME (seconds) Elapsed : 12
- done
Waiting For Client Cluster To CompleteServer Per second : 0
Server Open : 0
Client Attempted : 2706

Client Successful : 2704
Client Unsuccessful : 0

Executing Scripts
Client Aborted : 0
Remaining : 208
Server Per second : 16921

Server Open : 18
Client Attempted : 116092

Client Successful : 116077
Client Unsuccessful : 0
Client Aborted : 0
Remaining : 204
Server Per second : 27733

Server Open : 31

Validating Scripts
Validating Scripts
You can trial run test parameters before starting a test by adding the ValidateTest
function to your test script. The ValidateTest function trials the test by running once
through the Client Actions URL list. It performs an internal consistency check, scanning
through configuration files, error checking, and ensuring that all files referenced are
available.
ValidateTest verifies that all of the URLs are accessible. There is no time limit; it runs
as long as it takes to check each URL once. This process usually finishes quickly, unless
the servers are not responding or requests are timing out. If problems are encountered,
check the results file to troubleshoot the test.
During a trial run, the ValidateTest function generates a PCAP (packet capture) trace
file for each individual client and server unit involved in the test, called trace.pcap,
showing all the traffic requests and responses as the result of one simulated user. One or
more PCAP files shows all the packets sent and received at all interfaces, and can be
opened using any sniffer program, such as Ethereal, Netasyst (was Sniffer Pro), or
ClearSight. (For more information about accessing PCAP files, see the Analyzing Test
Results topic in the online Help.)
Also during a trial run, the ValidateTest function generates an XML trace file for
individual URLs, which contains errors, bindings of variables, response latency, and so
on. One trace file is generated per simulated user, called httptracefile_X_trace.xml, where
X is a number that represents the simulated user associated with the file. You can view this
file by using the URL Trace Tool.
To add the ValidateTest function to one of the sample scripts, you need to replace the
function calls to start client and server tests
(SPI_AV::ClusterController::StartClusteredTest function calls for
$serverClusterID and for $clientClusterID) in the script for the client side.
To validate a test:
1 In your test.tcl script, replace “StartClusteredTest” with “ValidateClus-

teredTest” as follows:
SPI_AV::ClusterController::ValidateClusteredTest $clientClusterID
$serverClusterID $testId
2 Before validating a test, you must add the UploadTest function to your script to
upload the test to all necessary units.
3 Once ValidateTest verifies that no errors were encountered during the test, it
returns a success.
4 Once the trial run is finished, you can view the trace files using the URL Trace Tool
(available on Windows only).

Printing and Collecting Test Results
Printing and Collecting Test Results

You can monitor a test while it is running by watching the real-time client and server
statistics messages that appear on the screen. You can also print the test results to a file.
To collect results you must configure your script via a callback function. See ““Executing
Scripts” on page 31” for more information on callback functions.
Printing Results to a Log File

When you run a test, it always creates results files with the extension .csv, which contains
the client and server-related test configuration and performance statistics. Results files
appear in the same location as your test XML files, except in a folder named “Results.”
The exact location of your test results depends on the specified testIDirectory and
testId variables in your test script:
set testDirectory "C:/TclAPI/2.xx/Build_0045/Appliance/
AdvDevConnsPerSecAppliance"
set testId "AdvDevConnsPerSecAppliance"
Test results for the individual client units are stored in a subdirectory named
<value_of_testDirectory>\<value_of_testId>\results\client-
subtest_<unit#>. Likewise, test results for the server are stored in a subdirectory named
<value_of_testDirectory>\<value_of_testId>\results\server-
subtest_<unit#>. Within each of those folders you will find two results files:
realtime.csv and summary.csv.
Additionally, for clustered tests, there is a folder called

<value_of_testDirectory>\<value_of_testId>\results\merged in which the
total aggregate results files, summary.csv, and realtime.csv, for both the client and
server are stored under “client” and “server” directories.

Debugging a Test Script
Debugging a Test Script

If you do not invoke a Tcl command properly, the system returns an error. Each error
description usually explains that the command failed and indicates the correct usage of the
command.
When you are running a test script, it can be difficult to detect which command failed.
Including puts statements in the test script can narrow the problem area, because you can
see the output at each point in the script where a puts statement occurs. You can also use
the built-in stack trace by calling set errorInfo, or type in the commands one at a
time.
Currently, each API function returns an appropriate error message indicating if it
encountered a problem but also returns a 1 if the operation completed successfully. So,
you can write code around each API function call that tests to see if it completed
successfully.
You can also turn debugging on for a TclAPI script for better debugging purposes. You
define a single variable, bEnableLogging, as in the following example taken from an
automatically generated test script, test.tcl:
set bEnableLogging 0; # Enable (1) to create a log file for enhanced
debugging
Setting the bEnableLogging variable to 1 causes a test_apilog.log file to be
generated in the same location where the script (test.tcl) resides.
Important: To ensure communication between the workstation on which you are running
the Scripting API for the Layer 4-7 Application and your appliance, or Spirent TestCenter
chassis, port number 1415 must not be blocked (for example, with a firewall or access
control list).

Chapter 3
Test Configuration Array
This chapter contains the syntax and descriptions of the parameters in a test configuration
array file.
In this chapter...
• Format of a Profile Entry . . . . 40
• Client Test Configuration Array Parameters . . . . 41
• Server Test Configuration Array Parameters . . . . 119
• Clustered Test Configuration Array Parameters . . . . 177
• Global Test Configuration Array Parameters . . . . 178

Chapter 3: Test Configuration Array
Format of a Profile Entry
Format of a Profile Entry

The typical format of an entry within the test configuration array is:
<ProfileType>,<ProfileName>,<ProfileAttribute><Value>
• <Profile Type>
Specifies the type of profile you are configuring.
• Client (Wa)
Enter one of the following types of client profiles: WaTestProfile, WaLoad-
Profile, WaInterface, WaNetworkProfile, WaSubnet, WaU-
rlList, WaUserProfile, WaUrlList, WaStaticRouteTable,
WaTelnetProfile, WaPPPGroupProfile, WaPPPoEGroupParams,
WaDDOSConfig, WaCapRepTCP, WaCapRepUDP, WaCapRepEth,
WaContent, WaFormDatabase, WaHttpContent
• Server (Wr)
Enter one of the following types of server profiles: WrTestProfile, WrNet-
workProfile, WrInterface, WrSubnet, WrStaticRouteTable,
WrServerProfile, WrTransactionProfile, WrDefaultTransac-
tionProfile, WrContent
• <ProfileName>
The name to give the profile on the target device. This name is used to reference this
profile from within other profiles.
• <ProfileAttribute>
One of the valid attributes for the corresponding profile type.
• <Value>
The value that the attribute will be assigned within the profile.

Client Test Configuration Array Parameters

This section contains parameters to create and manipulate client Load, Network, Interface,
Subnet, and User profiles.
The following profiles and parameters are described in this section:
• WaTestProfile
• WaLoadProfile
• WaNetworkProfile
• WaInterface
• WaSubnet
• WaUserProfile
• WaUrlList
• WaStaticRouteTable
• WaTelnetProfile
• WaPPPGroupProfile
• WaPPPoEGroupParams
• WaDDOSConfig
• WaCapRepTCP
• WaCapRepUDP
• WaContent
• WaFormDatabase
• WaHttpContent
• WaCookieJarList
• WaHostFile

WaTestProfile
Usage Test profile entries for the client within the test configuration array.
Syntax WaTestProfile,<Parameter> <value>
Parameters The input parameters and their values are described below:
• <Parameter> <value>
Specifies one of the following:
• Description {<description>}
Provide a description of the test. This description appears in the test results files.
• LoadProfile {<LoadProfile name>}
Specify the name of the Load Profile to use within this test. Load profile
parameters control the four test phases: ramp up, stepping, sustained and ramp
down. These parameters also control performance thresholds (load constraints)
and random error generation (burst mode) while testing.
• NetworkProfile {<NetworkProfile name>}
Specify the name of the Network Profile to use within this test. Network profile
parameters enable special routing (gateway and subnet), DNS (round robin), and
caching (proxy configuration) functionality, plus specify TCP parameters, such as
maximum segment size (MSS), attempts (retries), and packet contents (piggyback
GET request).
• Interface
Interface attributes within the Test Profile should adhere to the following syntax
for a single-unit test (that is, one client-side appliance, one server-side appliance,
or both):
WaTestProfile,Interface,<InterfaceID>,<Interface parame-
ter> <value>
Note: See “Clustered Test Configuration Array Parameters” on page 177 for
the syntax for Interface attributes within the Test profile for a clustered test.
◊ <InterfaceID>
An integer value within the range 0 - 3, depending upon the total number of
available interfaces on the appliance or Spirent TestCenter chassis.
◊ <Interface parameter> <value>
Specifies the parameter as one of the following values:
o Name {<interface profile name>}
Specify the name of the Interface Profile to be associated with the inter-
face you specified in <InterfaceID>.
o DDOSAttacks {<attackname1> <attackname2>}

If DDOS Attacks have been enabled on this interface, then use this
parameter to specify which attacks to use. If the name of an attack is
specified by itself, then default attack variables will be used (for example,
Smurf). To incorporate a user-defined DDOS attack, simply specify the
attack name, colon, and then attack profile name. (i.e.
Smurf:smurf_User1).
o DDOSConfig <globaldefs>
References a specific configuration file which houses the global DDOS
Attack variables.
o DDOSEnabled yes | no
Disables or enables DDOS (Distributed Denial of Service) attacks on a
specific interface. The default is no.
o PhysIf 0 | 1 | 2 | 3
Specify the physical port number associated with the current interface.
The default value for the PhysIf attribute is simply the interface index of
the interface. For example, the API assumes that you want interface 0 to
correspond to PhysIf 0, interface 1 to correspond to PhysIf 1, and so on.
o PhysIfDisplayString <string>
Specify a string to identify this physical interface (port) more easily in the
results (.csv) file. You cannot use commas within this parameter.
• HttpPerformance on | off
Enables or disables HTTP performance. This option provides a higher perfor-
mance HTTP transaction mode on a test-wide basis. A pre-built HTTP response,
derived from the default transaction profile for the server, is used to achieve the
higher performance. Specific performance/compatibility options are available
under the HTTP or HTTPS server configuration. Enabling this option automati-
cally configures HTTP 1.0 and disables KeepAlive and Persistence for all user
profiles used by the test. The default is off.
• SslAcceleration on | off
Enables or disables hardware SSL acceleration on a test-wide basis. The default
is off.
• SLBBinning on | off
Assists you in determining if the load balancing policy of the SLB (server load
balancer) is working as expected. Enabling this option provides detailed granular
information, such as statistics per server on a test-wide basis. The default is off.
• DetailedHSC on | off
Enables you to view the cumulative HTTP status codes received by the client dur-
ing a test. The default is off.
• DDOSEnabled on | off
Enables or disables DDOS (Distributed Denial of Service) attacks on a test-wide
basis. DDoS is enabled/disabled on a port basis. The default is off.

• SaveCookieJars on | off
Enables or disables cookie saving. When cookie saving is enabled, the client
records all cookies transmitted during a test, enabling you to create Cookie Jar
files automatically. Cookie Jar files must not exceed 64 megabytes. The default is
off.
• PktTrace on | off
Enables or disables the creation of a packet trace file. Enable this option if you
want the client to produce a PCAP (packet capture) file in addition to its normal
set of results files. The PCAP file (called trace.pcap) shows all packets sent and
received, and it can be read by many standard sniffer programs, such as Ethereal,
Netasyst (was Sniffer Pro), or ClearSight. The default is off.
• PktTraceBytes <integer>
The maximum size of the PCAP file in bytes. The maximum value that you can
enter is 9,999,360 bytes, which is also the default.
• UrlTrace on | off
Enables or disables the creation of an XML trace file. Enable if you want an XML
trace file for individual URLs, which contains errors, bindings of variables,
response latency, and so on. One trace file is generated per simulated user, called
httptracefile_X_trace.xml, where X is a number that represents the simulated user
associated with the file. You can view this file by using the URL Trace Tool. The
default is off.
• UrlTraceOnError on | off
Enable if you want only 4XX and 5XX HTTP error codes and content validation
failures reported. The default is on.
• UserLoadEnabled yes | no
Enable for a user-based profile. Use this type of profile if you want multiple load
curves, each of which describes the load for an individual user (client) profile.
User-based load profiles are associated with a unique user (client) profile. The
default is no.
• Notes
You can enter general notes about your test. Notes attributes within the Test Profile
should adhere to the following syntax:
WaTestProfile,Notes,<Notes Parameter><value>
Note: Tcl-sensitive characters are not permitted within any of the Notes
parameters.
◊ <Notes parameter> <value>

o Technician <string>
Enter the name or ID of the technician associated with this test.

o Author <string>
Specify the name or ID of the author associated with this test.
o DuTConfig <string>
Enter information about the device under test (DUT) configuration asso-
ciated with this test.
o RunName <string>
Enter a descriptive name for the current test run.
o Comments <string>
Enter any other comments associated with this test.
• RunTimeStatistics
Run-time statistics attributes within the Test Profile should adhere to the following
syntax:
WaTestProfile,RunTimeStatistics,<Stats Parameter><value>
◊ <Stats parameter> <value>
o TimeInterval <integer>
Specify the interval that you want to use for sampling real-time statistics
on the client. Values greater than 1000 are interpreted as being in seconds.
Values less than 1000 are interpreted as being in milliseconds.
WaLoadProfile
Usage Use the client load profile parameters to configure the amount of network traffic the client
will generate when you run your test. A test consists of a sequence of phases defined in a
load profile.
Client Load profile parameters control the four test phases: ramp up, stepping, sustained,
and ramp down. These parameters also control performance thresholds (load constraints),
and random error generation (burst mode) while testing.
Syntax WaLoadProfile,<LoadProfileName>,<Load parameter> <value>
• <LoadProfileName>
Specify the name for this Load Profile on the target device. This name is used to
reference this profile from within other profiles.
• <Load parameter> <value>
Provide a description of the load profile.
• LoadSpecification <value>

Defines the units in which the load is measured as one of the following values:
0 = Bandwidth
1 = Connections
2 = Connections/second
3 = SimUsers
4 = SimUsers/second
5 = Transactions
6 = Transactions/second
7 = BodyBytes
10 = SimUsers/hour
11 = Connections/hour
12 = Transactions/hour
Each value is described below:
◊ Bandwidth
Specifies the amount of data that can be transmitted in a fixed amount of
time over all combined interfaces. Bandwidth is usually expressed in bits per
second (Kbps).
◊ Connections
Defines the number of simultaneous network connections initiated from
the client. This setting generates enough load to reach and sustain a target
number of TCP connections. These TCP-based connections include protocols
such as HTTP, FTP, and SMTP. Open TCP connections depend on user arrival
rates (sessions/second), system efficiency, and user behavior, such as Think
Time. Like Sessions, TCP connections are an effect, not a cause, so specifying
the same number of TCP connections on different systems does not mean the
traffic generated will be the same. An open connection does not necessarily
have nonstop activity. This load type is the default value.
Use caution when interpreting results using this criteria because a rapidly
climbing number of open TCP connections usually means that the system is
overloaded or exhibiting latency.
Pay attention to the time it takes a TCP connection to complete, the time to
SYN/ACK, and the number of successful versus failed transactions at a
specified number of open TCP connections.
◊ ConnectionsPerSecond
This load type is often preferred by network equipment manufacturers for
testing network devices. One TCP connection can contain up to hundreds of
transactions, depending on client profile configuration and server response.

While the basic unit of load generated is Sessions (“Sessions” is the same as
“SimUsers” in the Layer 4-7 Application, the client calculates this load type
based on historical data. The client dynamically adjusts the rate of user arrival
(as in SessionsPerSecond) to match the targeted ConnectionsPer-
Second rate. When either ConnectionsPerSecond or Connection-
sPerHour is specified, the net load on a system is no longer affected by URL
list length.
◊ Sessions
This load type generates enough load to reach and maintain a target number of
concurrent simulated users. (“Sessions” in the TclAPI is equivalent to
“SimUsers” in the Layer 4-7 Application). It allows you to determine the
maximum number of concurrent users your device, infrastructure, or system
can handle. Use this specification if you want to keep applying load even after
the device under test fails. The amount of traffic generated depends on the per-
formance of the device under test. As the system slows down due to overload-
ing, generally each user takes longer to transverse through the URL list, and
the load "throttles back" and generates fewer new users.
◊ SessionsPerSecond
Maintains a target number of concurrent simulated users per second or hour.
Note that concurrent users does not always equate to active users. If you
configure a Think Time, only a few users might be active, while others are in a
think time with no network activity. (Same as “SimUsers per second” in the
Layer 4-7 Application.)
◊ Transactions
Defines the number of simultaneous transaction generated. This specification
generates and maintains enough load to reach an outstanding number of active
HTTP transactions, or GETs-in-progress. For example, HTTP 1.1 with
Persistence allows you to execute multiple transactions in a single connection.
Each transaction equates to the request and transfer of one object, which for a
website is call a hit. Under normal circumstances, all simultaneous transaction
will be actively setting up a connection, transferring data, or tearing down the
connection.
Note: The Transactions load type applies to HTTP and HTTPS transactions
only. For certain protocols, such as FTP, DNS, Streaming, POP3, SMTP, and
so on, you should use the Sessions load type.

Calibrating the load to generate a specific transaction/second while

maintaining realistic traffic is a challenge. Since load is generated as new
users arrive, existing users continue their transactions at non-uniform rates
due to Think Time and multiple level-2 URLs (embedded objects). The result-
ing increase in transactions/second may not be smooth due to traffic bursts
created by each individual user.However, this load type is useful for testing
proxy servers. For example, browsers normally maintain several persistent
connections to the proxy while executing multiple transactions on the same
connection throughout the duration of a session.
◊ TransactionsPerSecond
Gradually ramps up the number of HTTP transactions per second for the dura-
tion of the test. TransactionsPerSecond might not equal Connection-
sPerSecond when using HTTP 1.1 with Persistence.
◊ BodyBytes
Generates HTTP requests that solicit HTTP response bodies of the specified
length from the server and should be complemented with load constraints. The
BodyBytes load type only applies when using an emulated server.
◊ SessionsPerHour
Maintains a target number of concurrent simulated users per hour. Note that
concurrent users does not always equate to active users. If you configure a
Think Time, only a few users might be active, while others are in a Think
Time with no network activity. (Same as “SimUsers per hour” in the Layer 4-
7 Application.)
◊ ConnectionsPerHour
This load type is often preferred by network equipment manufacturers for
testing network devices. One TCP connection can contain up to hundreds of
transactions, depending on client profile configuration and server response.
While the basic unit of load generated is Sessions (“Sessions” is the same as
SimUsers in the Layer 4-7 Application), the client calculates this load type
based on historical data. The client dynamically adjusts the rate of user arrival
(as in SessionsPerHour) to match the targeted ConnectionsPerHour
rate. When either ConnectionsPerSecond or ConnectionsPerHour is
specified, the net load on a system is no longer affected by URL list length.
◊ TransactionsPerHour
Gradually ramps up the number of HTTP transactions per hour for the dura-
tion of the test. TransactionsPerHour might not equal Connection-
sPerHour when using HTTP 1.1 with Persistence.
Note: The TransactionsPerSecond and TransactionsPerHour load

types apply to HTTP and HTTPS transactions only. For certain protocols,
such as FTP, DNS, Streaming, POP3, SMTP, and so on, you should use the
SessionsPerSecond or SessionsPerHour load types.

• RandomizerSeedMode on | off
Enables or disables RandomizerSeedMode. Enable this mode and enter a num-
ber in the RandomizerSeed parameter to define the heights in the random phases
of the test. If this parameter is disabled or the value is 0, the seed is determined by
the time the test is executed. The last repetition of a random pattern is always the
same value as when the pattern started (the load height ends at the same height it
began). If a single repetition is selected, the load graph on the statistics window
will not display a random value. The default is off.
• RandomizerSeed <integer>
Defines the heights in the random phases of the test. The default is 1.
• Load Profile Steps Parameter
Steps parameter entries within the LoadProfile should adhere to the following
syntax:
WaLoadProfile,<LoadProfileName>,Steps,<Parameter> <value>
◊ <Parameter> <value>
o DefaultTimeScale Milliseconds|Seconds|Minutes|Hours
Specify the default time scale unit for each step. Each step can override
this value by specifying its own time scale. The default is Seconds.
o Step
Step parameter entries within the LoadProfile should adhere to the
following syntax:
WaLoadProfile,<LoadProfileName>,Steps,Step,<Step#>,
<Parameter> <value>
∇ Label {label} - Enter a name to identify the step you are
defining. This label must be an alphanumeric string.
∇ Pattern Flat | Stair | Burst | Sinusoid |
Random - The shape of the load curve. The default is Flat.
∇ TimeScale Default | Milliseconds | Seconds | Min-
utes | Hours - Specify the unit of time for the selected step’s
load generation. If you want to experiment with a test of short dura-
tion, specify Default which uses the value of the default time scale.
After you perfect the test, change the time scale to a different unit of
time and scale the duration of your test.
∇ Num <integer> - If you are using a stair, burst, sinusoid, or
random pattern, enter the number of times that you want the pattern
to repeat. While it is possible to set up to 100 repetitions, the system
performs best if you limit your values between 1 and 10. The actual
load generation while running the test will not be adversely affected.
The default is 1.

∇ Height <integer> - Height of the load curve measured in units

specified via LoadSpecification. Enter the total amount of load
related to the load specification type (for example, Connections) that
the client achieves. To keep the client from overwhelming your net-
work, start small and increase these parameters proportionately.
There is no minimum height requirement, but the upper limit must
not exceed 10,000,000.
∇ RampTime <integer> - Amount of time each step takes to reach
the load type (sessions, connections, and so on) applied to height, in
seconds. Once that load level is reached, Step Steady Time begins.
There is no minimum limitation, but the upper limit must not exceed
40,000,000. If you are using a Sinusoid pattern, setting RampTime to
1 will result in a smoother waveform. For example, if the ramp up
time is 20 seconds, and the load (height) is 30, the client adds load so
30 units of load occur by the end of 20 seconds. If you increase the
number of connections to 100, you should also increase the ramp
time to 80 seconds. When using a Sinusoid pattern, use the period to
describe the period of the sinusoid; the amount of time (or frequency)
the waveform takes to complete one cycle.
The Ramp phase is especially useful if you already know the relative
performance threshold of a system. For example, to test a firewall,
you can design a test that ramps up quickly to 2500 connections a
second (conns/sec), then steps 50 conns/sec for 10 seconds to pin-
point the threshold.
∇ SteadyTime <integer> - Amount of time to hold the load at the
height (that is, the amount of time the step takes). Larger Step Heights
should have equally increased step steady times. If the step time is
longer than it takes for the load to reach the unit count related to the
load specification type, the client decreases load generation to keep
the outstanding load at a steady state equal to that of the desired ses-
sion count. There is no minimum limitation, but the upper limit must
not exceed 40,000,000.
If you use a Sinusoid pattern, set the Steady Time to 1 to achieve a
smooth or waveform.
∇ Period <integer> - For Sinusoid pattern only. Enter the
amount of time the client takes to gradually achieve the total load
designated in the Height parameter. Ramp time allows self-tuning
communications to balance the load at the start of a test run. There is
no minimum limitation, but the upper limit must not exceed 1,000.

• Load Profile LoadConstraints Parameter

Use Load constraints to control performance thresholds. Constraints are useful if
you already know the performance limits of a system. For example, if a firewall
can support up to 16,384 connections, but you want to identify its maximum
error-free connection rate for 10k files, you would use ConnectionsPerSecond as
the load specification and set MaxOpenConnections to 16384. A disabled
constraint means there is no limit to the constraint. A zero (0) means no load.
Load constraint parameter entries within the LoadProfile should adhere to the fol-
lowing syntax:
WaLoadProfile,<LoadProfileName>,LoadConstraints,
<Parameter> <value>
o MaxBandwidth <integer>
Controls the upper limit for the incoming bandwidth that occurs through-
out the test. If the maximum is exceeded, no more Sessions are generated
until the incoming bandwidth falls below this value. The default is empty.
o MaxBorn <integer>
Controls the upper limit for the total number of Sessions created during a
test.
o MaxBirthrate <integer>
Controls the upper limit for the number of Sessions created in any second
throughout the test.
o MaxLiving <integer>
Controls the upper limit for the number of concurrently running Sessions.
o MaxConnectionsAttempts <integer>
Controls the upper limit for the number of connection attempts that are
made throughout the test.
o MaxNewConnectionsPerSecond <integer>
Controls the upper limit for the number of open connections created in
any second throughout the test.
o MaxOpenConnections <integer>
Controls the upper limit for the number of open connections. The default
is 100.
o MaxConnectionsErrorsPercent <integer>
Controls the upper limit for the percentage of connection errors that occur
during any second throughout the test.
o MaxTransactionAttempts <integer>
Controls the upper limit for the number of transaction attempts that are
made throughout the test.

o MaxNewTransactionsPerSecond <integer>
Controls the upper limit for the number of transactions that are requested
at any second throughout the test.
o MaxTransactionsErrorsPercent <integer>
Controls the upper limit for the percentage of errors that occur during any
second throughout the test.
WaNetworkProfile
Usage The client network profile describes the DNS, Proxy, and TCP characteristics of your
network. Use the network profile parameters to configure the network characteristics that
you want to emulate.
Client Network profile parameters enable special routing (gateway and subnet), DNS
(round robin) and caching (proxy configuration) functionality, plus specify TCP
parameters, such as maximum segment size (MSS), attempts (retries), and packet contents
(piggyback GET request).
These entries are equivalent to setting parameters in the Client Network tab of the Layer 4-
7 Application.
Syntax WaNetworkProfile,<NetworkProfileName>,<Network parameter>

<value>
• <NetworkProfileName>
Specifies the name for this Network Profile on the target device. This name is used to
• <Network parameter> <value>
Provide a description of the network profile.
• RoundRobinDNS on | off
Enable or disable Round Robin DNS. Enabling this option prompts the client to
resolve domain names in the URL lists for every simulated user request. If the
URL list used contains hostnames (fully qualified domain names) instead of IP
addresses, the client normally queries the DNS server and caches the result for
future transactions. The default is off.

• FairnessThreshold <integer>
Specifies the throughput (fairness) threshold per connection that you expect when
testing a DUT/SUT (device/system under test) that performs bandwidth manage-
ment, traffic shaping, or QoS guarantee. You specify the fairness threshold per
connection in bytes/second. All data sent and received inside a particular connec-
tion is recorded. The rate for every connection is calculated as follows:
(bytes sent + bytes received) / connection lifetime
This calculation is based on TCP bandwidth, that is, the TCP data minus any
Ethernet, IP, or TCP headers. The result determines if a connection is below or
above the specified threshold.
For example, if a DUT is configured to prevent a connection from exceeding 2048
bytes/second, you would specify a fairness threshold of 2048. The number of con-
nections that exceeded this throughput threshold would appear in the client real-
time statistics.
The default is 2147483647.
• Proxy,<Proxy parameter> <value>
The Proxy Client allows you to run Tcl API tests via a proxy server. (This option
applies only to HTTP.) When using this option, the URL list must explicitly con-
tain the protocol used (that is, http://). For example, an HTTP URL list entry
would be 1 http://1.2.3.4/abc.html, not just 1 1.2.3.4/abc.html.
Proxy attributes within the Network Profile should adhere to the following syntax:
WaNetworkProfile,<NetworkProfileName>,Proxy,
<Proxy parameter> <value>
◊ <Proxy parameter> <value
o MaxTxnPerProxyConnection <integer>
Specifies the maximum transactions per connection, before the client
closes the TCP connection with the proxy, regardless of whether the desti-
nation URL is from the same server. The default is 100.
o ProxyConnectionPersistence on | off
Enables or disables persistent connections. If enabled, multiple requests
can use the same connection to the proxy. The default is on.
o MaxProxyConnections <integer>
Specifies the maximum number of connections per client allowed in a
session. A browser such as IE 5.X can make up to 50 persistent
connections to a proxy. During any test, the number of sessions can reach
the maximum Step Height value. The default is empty.

o ProxyServerAddress <X.X.X.X>
Specifies the proxy server address to which to send requests. When
designating the proxy server, make sure that the proxy server can access
the client’s test interfaces as if it were a server. The default is an empty
string.
o ProxyServerPort <integer>
Specifies the proxy server port.
o ProxyConnectionHeader on | off
Enable or disable the proxy connection header. Enabling this header
ensures that the proxy server being tested knows that a client explicitly
uses a proxy server. The default is off.
o ProxyClientMode on | off
Enable or disable the proxy client mode. Enabling this mode allows
the client to make requests to a server via a proxy. This means that HTTP
requests must be fully qualified so that the proxy, upon receiving a
request, can make the request on behalf of the client. The client, in this
case, is Avalanche. The default is off.
• TCPOptions,<TCPOptions parameter> <value>
TCPOptions attributes within the Network Profile should adhere to the following
syntax:
WaNetworkProfile,<NetworkProfileName>,TCPOptions,
<TCPOptions parameter><value>
◊ <TCPOptions parameter> <value>
o RandomizePort on | off
Enable this option if you want to randomly select client
TCP ports. If you do not enable this option, the client selects ports
sequentially. This option applies only if you have more than one URL in
your URL list and the Enable Persistence option is not enabled. The
default is off.
o TCPMaxSegSize <integer>
Directs the targeted server to send TCP segments not exceeding the
specified maximum segment size (MSS). The MSS will be declared
initially in the TCP options field in the SYN packet for each connection.
This is especially useful for the emulation of clients on specific IP stacks
or PPP links. The default value is 1460, which is also the maximum value
you can specify. You can enter a value between 128 and 1560.

o TCPReceiveWindowSize <integer>
Specifies the receive window in which you want the TCP stack to send
TCP segments. The receive window informs the peer how many bytes of
data the stack is currently able to receive. The supplied value is used in all
segments sent by the stack. The number you enter can range from 0 to
1073741823. The default is 32768.
o TCPDelayedAcks on | off
Enable this option to cause the TCP stack to implement the Delayed ACK
strategy, which attempts to minimize the transmission of zero-payload
ACK packets. The default is on.
Acknowledgements will be deferred in the hopes of piggybacking them
on top of valid data packets. If successfully deferred, these acknowledge-
ments are free, in the sense that they consume no additional bandwidth.
o TCPDelayedAckTimeout <integer>
If Delayed Acks is enabled, this timeout value specifies the maximum
time the TCP stack will wait to defer ACK transmission. If this timer
expires, the stack will transmit a zero-payload acknowledgement. The
default is 200.
o TCPDelayedAckBytes <integer>
Enter the number of bytes of data, after the receipt of which, you want the
TCP stack to send an ACK packet. This parameter is only used if TCPDe-
layedAcks is enabled. The default is 2920.
o TCPCongestionControl on | off
Enable this option to invoke the TCP stack's congestion control
mechanism. If checked, the TCP stack implements Slow Start and
Congestion Avoidance, according to RFC 2581. The default is on.
o TCPTimeout <integer>
Enter a TCP Timeout value in milliseconds which will override the inter-
nally calculated TCP stack timeout value. The TCP stack calculates the
retransmission timeout value internally. This calculation can be
overridden by enabling TCPTimeoutOverride and supplying a
timeout value. This value is used for the first transmission of a particular
data or control packet; it is doubled for each subsequent retransmission.
The default is 2000 milliseconds.
o TCPTimeoutOverride on | off
Enable or disable the TCP Timeout override. If enabled, the manual
timeout specified in TCPTimeout is used. The default is off.

o TCPRetries <integer>
Specify the number of times a timed-out packet should be
retransmitted before aborting further retransmission. If the client gets no
response after the configured number of retries have been attempted, the
error is logged in the results.CSV file as a TCP timeout when a SYN is
sent and no SYN/ACK from the server is received. The default is 2.
o TCPInactivityTimeout <integer>
Connections inactive for this length of time are reset (the stack sends an
RST segment) and abandoned. A value of 0 disables the timer. This timer
must be disabled for each streaming test. The default is 0.
o TCPPiggybackGet on | off
Enable or disable piggybacking the HTTP GET request to cause the stack
not to send an ACK packet after receiving a SYN/ACK and before send-
ing the connection's first data packet (available only for HTTP). The
default is off. The default behavior for a TCP handshake from the client is
as follows:
SYN ->
<-SYN/ACK
ACK with GET ->
o IP6MaxSegSize <integer>
Enter the maximum Internet Protocol Version 6 (IPv6) segment size (in
bytes) you want the TCP stack to receive. Enter a value between 148 and
1440. The default is 1440.
• IpReassemblyTimeout <integer>
Specify the fragment reassembly timer in milliseconds. Enter the maximum time
in milliseconds that the IP stack should wait for subsequent fragments after
receiving the first fragment of an IP datagram. If the entire datagram has not been
received by this time, the entire datagram is discarded. The default is 30,000.
WaInterface
Usage The interface profile describes each interface port on the client. For each interface port on
the client, assign an interface profile to that port.
Client Interface parameters enable gratuitous ARP, enable virtual routing, specify router
IP address/netmask bits, enable DDOS attacks, and specify the port number.
Note: Do not use both a subnet and virtual router to configure routing for the same test. If
you do, in most cases, the virtual router will take precedence.
These entries are equivalent to setting parameters in the Client Ports tab of the Layer 4-7
Application.

Syntax WaInterface,<InterfaceProfile Name>,<Interface parameter>

<value>
• <InterfaceProfile Name>
Specifies the name for this Interface Profile on the target device. This name is used to
• <Interface parameter> <value>
Provide a description of the interface profile.
• GratuitousARP on | off
Enable or disable ARP (Address Resolution Protocol). Enable this feature to
broadcast an ARP (Address Resolution Protocol) request with the port’s IP address
at the beginning of each test. This ensures that a device connected to the port has
the correct ARP cache data. The default is on.
• Subnets {<subnet profile name1> <subnet profile name1>}
Specify the subnet profile name(s) of the current subnet(s).
• Router <Router parameter> <value>
Router attributes within the Interface Profile should adhere to the following
syntax:
WaInterface,<InterfaceProfileName>,Router,
<Router parameter> <value>
◊ <Router parameter> <value>
o IpAddress <X.X.X.X>
The outbound address of the router emulated by the interface. Use CIDR
notation, that is, specify the address in dotted decimal notation.
o NetmaskBits <integer>
The number of bits in the specified network that comprise the network
part of the address.
o StaticRouteTable <StaticRouteFilename>
Specify the name of the XML file containing the static routing table. Use
the WaStaticRouteTable parameter to populate the route table.
o Enabled on | off
Enable or disable this router profile. The default is off.
Note: You can enable only one router profile definition (via the Router or RouterSet
parameter) at any one time. If you enable more than one router profile definition, all
profiles will default to “off.”

• FlatSubnet <FlatSubnetNumber> <FlatSubnet parameter>

<value>
Use the FlatSubnet option to configure a "flat" subnet (that is, one single subnet
that you can use for multiple ports). When you generate a flat subnet, you assign
the subnets IPs to each port so that they do not overlap. You can define the begin-
ning IP (the offset value), count (the total number of IPs in the range to use), and
the increment (the next IP in the range to use).
Interface profile FlatSubnet attributes within the test configuration array should
adhere to the following syntax:
WaInterface,<InterfaceProfileName>,FlatSubnet,<FlatSub-
netNumber>,<FlatSubnet Parameter> <value>
◊ <FlatSubnetNumber>
Iterates with each new flat subnet definition from 0 onwards.
◊ <FlatSubnet parameter><value>
o Name <profile name>
Enter the baseline subnet profile name from which this flat subnet is
derived.
o Offset <integer>
Enter the offset value. The offset value determines the beginning IP
address in the range of hosts for the associated subnet. For example, if the
range is 192.168.1.1-192.168.12, and the offset is 1, then the first IP used
to send traffic is 192.168.1.2. The default is 0. The offset value must be
compatible with the IP range in the named profile and the <count> and
<increment> values specified.
o Count <integer>
Enter the total number of hosts in the range to use. For example, if the
starting IP is 10.10.10.1 and the ending IP is 10.10.10.10, the count could
be 10 to use all of the IPs. The default is 254. The value you specify must
be compatible with the <offset> and <increment> values specified.
o Increment <integer>
Enter the increment value. The increment value that determines the next
IP in the range to use. For example, if the beginning IP is 10.10.10.1 and
the increment is 2, the next IP used is 10.10.101.3. The default is 1.
User profile FlatSubnet attributes within the test configuration array should adhere
to the following syntax:
WaInterface,<InterfaceProfileName>,FlatSubnet,<FlatSub-
netNumber>,UserProfile,<UserProfileNumber>,<UserProfile
Parameter> <value>
◊ <UserProfileNumber>
Iterates with each new flat subnet user profile association from 0 onwards.

◊ <UserProfile parameter><value>
o Name <profile name>
Enter the user profile name to associate with the current flat subnet.
o Percentage <integer>
Specify the percentage load that this particular user profile will generate
(from 0 - 100%).
• RouterSet <RouterSet parameter> <value>
Use the RouterSet option to configure a router for this subnet.
Interface profile RouterSet attributes within the test configuration array should
WaInterface,<InterfaceProfileName>,RouterSet,<RouterCon-
figNumber>,<RouterSet Parameter> <value>
◊ <RouterConfigNumber>
Iterates with each new router definition from 0 onwards.
◊ <RouterSet parameter><value>
o IpAddress X.X.X.X
Specify a virtual router IP address.
Specify the virtual router’s netmask.
WrStaticRouteTable to populate the static routing table.
o InsertVlanTag on | off
Enable or disable VLAN tagging. The default is off.
o VlanId <integer>
Specify a VLAN ID to include when InsertVlanTag is enabled. The
default is 1.
o Enabled on | off
Interface profile RouterSet MacMasquerade attributes within the test configura-
tion array should adhere to the following syntax:
WaInterface,<InterfaceProfileName>,RouterSet,<RouterCon-
figNum>,MacMasquerade,<MAC Parameter><value>

◊ <RouterConfigNum>
◊ <MAC parameter> <value>
o Enabled on | off
Enable or disable MAC masquerading. The default is off.
o Mac0 <00-FF>
Specify the first MAC address byte. The default is 00.
o Mac1 <00-FF>
Specify the second MAC address byte. The default is 00.
WaSubnet
Usage Use the Subnet parameters to configure subnet configuration profiles.

Client Subnet parameters enable you to define static routing, IP fragmentation, realism,
PPP/PPPoE, and IPSec for one or more subnet profiles, plus subnet and netmask details.
These entries are equivalent to setting parameters in the Client Subnets tab of the Layer 4-
7 Application.
Tip: You can also use a virtual router to configure routing. However, do not use both a
subnet and virtual router to configure routing for the same test. If you do, in most cases,
the virtual router will take precedence.
Syntax WaSubnet,<SubnetProfileName>,<parameter> <value>
• <SubnetProfileName>
Specify the name for this subnet profile on the target device. This profile name is used
to reference this profile from within other profiles and uniquely identifies the subnet
configuration.
• <parameter> <value>
Specify one of the following:
Write a short sentence describing the subnet configuration profile.
• IpVersion 4 | 6
Enter either 4 for IPv4 or 6 for IPv6 based on the IP version of the gateways.
• Network <X.X.X.X>
(IPv4 only.) Enter the network address of your subnet, using CIDR notation (dot-
ted decimal).

• NetmaskBits <integer>
(IPv4 only.) Enter the number of bits in the network part of the address. For exam-
ple, 24 represents 255.255.255.0, while16 represents 255.255.0.0. The default is
24.
• IpAddressRange
(IPv4 only.) Subnet profile IpAddressRange attributes within the test configura-
WaSubnet,<SubnetProfileName>,IpAddressRange,
<Ip Parameter><value>
◊ IpAddressRange <X.X.X.X-X.X.X.X>
Enter an IP address or a range of IP addresses from which you want to gener-
ate traffic for your test ports. Use CIDR notation (dotted decimal). Alterna-
tively, leave this parameter blank to use all addresses that could exist on the
network that you specify in the Network and NetmaskBits parameters.
Note: The appliance uses only the address or addresses that you specify to emulate
clients. However, all addresses in the subnet are assigned to the parent interface
for packet routing purposes. Therefore, do not assign the same addresses to more
than one interface. For example, the ranges 192.168.1.1-192.168.1.10 and
192.168.1.11-192.168.1.20 do not overlap, but subnets 192.168.1.1-192.168.1.10/
24 and 192.168.1.11-192.168.1.20/24 actually belong to the same subnet because
of the netmask bits, and are therefore bound to the same interface.
• SendSide
Subnet profile SendSide attributes within the test configuration array should
WaSubnet,<SubnetProfileName>,SendSide,
< SendSide Parameter> <value>
◊ ConnectionNoise <integer>
The percentage of desired packets lost per million packets sent. This entry
emulates noisy network traffic by deliberately dropping a certain number of
packets at random. Enter the percentage packet loss multiplied by 1000 on the
link. For example, 50% packet loss equates to a ConnectionNoise value of
◊ ConnectionSpeed <integer>
Enter the bits per second (bps) or link speed that a simulated user will use to
connect to a network. The default is 0.
◊ NPacketsToDrop <integer>
Enter the number of packets to drop. When a packet must be dropped, the
number of successive packets dropped is decreased by one. Any succeeding
packets for that same subnet will be dropped, until the packets dropped value
in the subnet becomes zero. Once this value is zero, the cycle repeats. The
default is 0.

◊ EndToEndDelay <integer>
Enter the delay in milliseconds that emulates the distance of the subnets
involved. The default is 0. To this delay, you can also specify a delay variation
method (see DelayVarianceMethod) that emulates the queuing and processing
delay at intermediate hops in the internet/network. The sum processing of
these two delays is the total delay used per packet. You configure these delays
on a per subnet basis for outgoing and incoming traffic separately (that is,
Receive Side and Send Side of the interface).
◊ DelayVarianceMethod 0 | 1 | 2
Specify the method used to determine the delay variance. Possible values
are 0, 1, or 2: 0 is equivalent to none (no delay variation is applied), 1 is
equivalent to uniform distribution (a uniform distribution has the same
probability for all the members of the population), and 2 is equivalent to
normal distribution, frequently referred to as a Bell Curve, which has a
concentration of members around the middle and less on the tails of the curve.
The default is 0.
◊ DelayVarianceVal1 <integer>
If you specified 1 or 2 for the DelayVarianceMethod, then this parameter
specifies the start of the delay variances. The default is 0.
specifies the end of the delay variances. The default is 0.
• RecvSide
Subnet profile RecvSide attributes within the test configuration array should
WaSubnet,<SubnetProfileName>,RecvSide,
<RecvSide Parameter><value>
◊ ConnectionNoise <integer>
Enter the percentage of desired packets lost per million packets received. This
entry emulates noisy network traffic by deliberately dropping a certain num-
ber of packets at random. The default is 0.
◊ ConnectionSpeed <integer>
The bit rate that a simulated user will use to connect to a network. This entry
calibrates the bits per second (bps), or link speed. The default is 0.
◊ NPacketsToDrop <integer>
Sets the number of packets to drop. When a packet must be dropped, the
number of successive packets dropped is decreased by one. Any succeeding
packets for that same subnet will be dropped, until the packets dropped value
in the subnet becomes zero. Once this value is zero, the cycle repeats. The
default is 0.

◊ EndToEndDelay <integer>
Enter the delay in milliseconds that emulates the distance of the subnets
involved. The default is 0. To this delay, you can also specify a delay variation
method (see DelayVarianceMethod) that emulates the queuing and processing
delay at intermediate hops in the internet/network. The sum processing of
these two delays is the total delay used per packet. You configure these delays
on a per subnet basis for outgoing and incoming traffic separately (that is,
Receive Side and Send Side of the interface).
◊ DelayVarianceMethod 0 | 1 | 2
Specify the method used to determine the delay variance. Possible values are
0, 1, or 2: 0 is equivalent to none (no delay variation is applied), 1 is
concentration of members around the middle and less on the tails of the curve.
The default is 0.
specifies the start of the delay variances. The default is 0.
specifies the end of the delay variances. The default is 0.
• IpQosValue <integer>
(Send side only) Specify the type of service. This value is any number between 0
and 255 that is inserted in the IP header of all outgoing segments from the subnet.
The default is 0.
• InsertVlanTag on | off
• VlanId <integer>
Specify a VLAN ID to include in every packet transmitted from this subnet. This
ID will be used when InsertVlanTag is enabled. The default is 1.
• VlanPriority <integer>
Specify the user priority for the VLAN. The valid range is 0 to 7. The default is 0.
• VlanCFI <integer>
Specify the one-bit canonical format indicator (CFI) for the VLAN. The default is
0.
• IpFrag
Subnet profile IpFrag attributes within the test configuration array should adhere
WaSubnet,<SubnetProfileName>,IpFrag,
<IpFrag Parameter><value>

◊ Enabled on | off
Enable or disable IP Fragmentation Enable to fragment all datagrams
transmitted from this subnet. The default is off.
◊ FragmentSize <integer>
The number of bytes contained in each fragment. Any number is accepted,
however, fragment size must be a multiple of eight, so that the IP stack rounds
up to the nearest multiple of eight. The default is 128.
◊ PacketsPerMillion <integer>
Enter the fragmentation index which equates to a fragmentation percentage
multiplied by 10000. For example 5% packet fragmentation equates to a
PacketsPerMillion value of 50000. The default is 50000.
◊ SendInReverseOrder on | off
Enable or disable transmitting fragments in reverse order. This option allows
testing of worst-case reassembly scenarios. The default is off.
◊ SendFirstOnly on | off
Enable or disable sending the first fragment. Enable to transmit only the first
fragment of each datagram. All other fragments are discarded. If you enabled
SendInReverseOrder, only the fragment that would have been sent last is sent.
This option allows you to test reassembly timeout mechanisms. The default is
off.
◊ OverlapFragments on | off
Enable or disable sending overlapping fragments. Enable to cause the IP stack
to create and send random, but legitimate, IP fragments whose data offset and
length are randomly selected so that the receiving end sees overlapping data in
the fragments it receives. The overlapping fragment will not have enough data
for the receiving end to complete the reassembly, and overlapping fragments
are sent only if the original IP datagram is at least 24 bytes long. The best
effort is made to insert the overlapping fragments in between regular
fragments, but they are not guaranteed to always be inserted (because of their
random nature), and they are never inserted after the last regular fragment is
sent. This option is useful for testing the reassembly mechanisms at the other
end. The default is off.
• MacMasquerade
Subnet profile MacMasquerade attributes within the test configuration array
WaSubnet,<SubnetProfileName>,MacMasquerade,
<MAC Parameter> <value>
◊ Enabled on | off
◊ Mac0 <00-FF>
Enter the first MAC address byte. The default is 00.

◊ Mac1 <00-FF>
Enter the second MAC address byte. The default is 00.
• UsePPPoE on | off
Enable or disable additional PPP parameters required for the Point-to-Point over
Ethernet (PPPoE) Protocol. Enable to use a PPPoE configuration, and then specify
the PPPoE configuration that you want to apply to the subnet. The default is off.
• PPPoEGroupName Default {<PPPoE Profile File Name>}
Specify the name of the PPPoE profile to use
• UsePPP on | off
Enable or disable Point-to-Point Protocol (PPP) parameters. The default is off.
• DefaultGatewayEnabled on | off
Enable or disable the use of a default gateway. The default is off. When you enable
the default gateway, the client creates and enables the static routing table that
includes the specified gateway address. Therefore, if you enable this parameter,
you must also: configure the appropriate static routing table (see WaStati-
cRouteTable), enable it via WaSubnet,<SubnetProfile-
Name>,Router,Enabled, reference the appropriate routing table via
WaSubnet,<SubnetProfile Name>,Router,StaticRouteTa-
ble,<StaticRouteFilename>, and configure this table with the default gate-
way address (see GatewayAddress <X.X.X.X>).
• RandomizeIPAddr on | off
Enable or disable allowing the client to randomly select an IP address from the IP
address range. If you do not enable this parameter, the client selects the IP address
sequentially. The default is off. This parameter is for IPv4 subnets only.
• PPPGroupName Default {<PPP Profile File Name>}
Specify the name of the PPP profile to use.
• UserProfile
Subnet profile UserProfile attributes within the test configuration array should
WaSubnet,<SubnetProfileName>,UserProfile,
<UserProfileNumber>,<UserProfile Parameter> <value>
◊ <UserProfileNumber>
Iterates with each new user profile definition from 0 onward. Up to 100 user
profiles per subnet are supported.
◊ <UserProfile Parameter> <value>
o Name <User Profile Name>
Specify the User Profile name.

o Percentage <integer>
Enter the percentage load that this particular user profile will generate
(from 0 – 100%).way.
• Router
Router profile attributes within the test configuration array should adhere to the
following syntax:
WaSubnet,<SubnetProfileName>,Router,<Router Parameter>
<value>
◊ <Router Parameter> <value>
Specify the name of the XML file containing the static routing table.
• MacAddressRanges
Subnet profile MacAddressRanges attributes within the test configuration array
WaSubnet,<SubnetProfileName>,MacAddressRanges,<Ranges
Parameter> <value>
Note: You can specify only one MAC address range.
◊ <Ranges Parameter> <value>

o MacAddressRange <XX:XX:XX:XX:XX:XX-
XX:XX:XX:XX:XX:XX>
Specify the MAC address range (MAC1-MAC2).
• IPSec
Use the IPSec parameters to configure the client VPN settings. There are two basic
types of VPN connections. One type is a LAN-to-LAN connection (or site to site).
The other is a client-to-LAN connection, linking a client such as a remote dialup
user to a LAN (remote access).
For both types of VPN connections, data between hosts at the endpoints of the
connection passes through the public Internet. For the communication between the
hosts to be secure, a tunnel is established that spans the unprotected area of the
communication (the Internet) where the data is vulnerable to being intercepted and
read.
Subnet profile IPSec attributes profile attributes within the test configuration array
WaSubnet,<SubnetProfileName>,IPSec,<IPSec Parameter>
<value>

◊ <IPSec Parameter> <value>

o Enabled on | off
Enable or disable IP security for this subnet. The default is off.
o IkePhase1Mode Aggressive | Main
Specify the mode to use for Phase 1 exchange. This mode determines the
messages that are exchanged between the initiator and responder to nego-
tiate the Phase 1 Security Association (SA).
∇ Aggressive mode is used to negotiate IKE Phase 1 SAs when the pro-
tection of identity information is not necessary. This allows the mes-
sages involved in the key exchange and authentication to be
transmitted together and reduces the number of round trips required
for the negotiation. The drawback to Aggressive mode is that the
identity information is not protected. The default is Aggressive.
∇ Main mode is used to negotiate IKE Phase 1 SAs when the protection
of identity information is necessary. There are six messages
exchanged during the first phase of the IKE negotiation in Main
mode. The messages exchanged vary depending on the method used
to authenticate the peers.
Note: IKE operates in two different phases (Phase 1 and Phase 2) during the nego-
tiation process. Each phase is used to establish SAs that will be used to negotiate
the tunnel. During the phases, messages are exchanged between the VPN gate-
ways involved in the negotiation.
o AuthMeth Preshared | RSA | XAuth

Enter the authentication method for phase 1.
∇ Preshared (site-to-site only) - If you enter Preshared, you must
also include the PresharedKey parameter to specify the key string
for this type of authentication.
∇ RSA (site-to-site only) - If you enter RSA, you must also include the
CACertFileLocation and CertFileLocation parameters to
specify the name and location of the certificate files to upload.
∇ XAuth (Extended Authentication, remote-access only) - If you enter
XAuth, you must also include the Type parameter to indicate the
type of XAuth for phase 1 (Generic, Cisco, or Nortel). See <XAuth
Parameter> <value> for more information.
o IsakmpIdentification <string>
Enter the Internet Security Association and Key Management Protocol
(ISAKMP) identification payload. ISAKMP defines procedures and
packet formats to establish, negotiate, modify and delete security associa-
tions.

o PresharedKey <string>
Enter the key string to use when doing Preshared key authentication. Pre-
shared means that the parties agree on a shared, secret key that is used for
authentication in an IPSec policy.
o CACertFileLocation <file path>
Enter the location and name of the certifying authority's certificate file to
be incorporated within the test, for example, {c:\\certs\\cacert.pem}.
The X.509 format certificate file name of the tunnel endpoint. (Enabled
only when the Authentication method specified for AuthMeth is RSA.)
Note: Certificate files are generally large. The MTU (maximum transmis-
sion unit) containing the IKE message can be larger then 1500 bytes, in
which case the packet will be silently dropped by the NIC. Therefore, you
should turn on fragmentation (e.g., with a size of 512 or 1000 bytes) for
both the client and server subnets.
o CertFileLocation <file path>

Enter the location and name of the certificate file to incorporate within the
test, for example, {c:\\certs\\cert.pem}.
o PrivKeyFileLocation <file path>
Enter the location of the Private Key file to be incorporated within the
test, for example, {c:\\certs\\privkey.pem}.
o EncAlg DES | 3DES | AES-128 | AES-192 | AES-256
Specify the encryption algorithm to used for Phase 1 to transform the pay-
load data in the packets from an intelligible form (plaintext) into an unin-
telligible form (ciphertext), and back:
∇ DES: The Data Encryption Standard, defined by the U.S. govern-
ment. DES is a symmetric 64-bit block cipher that uses a 56-bit key.
∇ 3DES: A variant of DES, and is the most accepted method. 3DES is a
combined set of two DES keys totalling 112 bits. Due to its larger
size, 3DES is considered much more secure that DES.
∇ AES-128: AES (Advanced Encryption Standard) with a 128-bit key.
∇ AES-192: AES with a 192-bit key.
o HashAlg MD5 | SHA-1
Specify the hash authentication method used for Phase 1 to verify that the
packets being received were sent by the stated source:
∇ MD5 - A message-digest algorithm that derives a secure, irreversible,
cryptographically strong hash value. This is considered less secure
than SHA-1.

∇ SHA-1 - The Secure Hash Algorithm version one, part of the U.S.
Digital Signature Standard (DSS). This algorithm is considered very
secure.
o DHGroup MODP-768 | MODP-1024 | MODP-1536
Specify the Diffie-Hellman group for Phase 1:
∇ MODP-768 (group 1)
The size of the group determines the level of security of the Diffie-Hell-
man key exchange. (The higher the group number, the greater the secu-
rity.) The groups use traditional exponentiation over a prime modulus
(MODP). These options are key exchanges only and do not encrypt the
data.
o Ph1EncryptPkt3 on | off
Enable or disable encryption of the third packet of Phase 1 aggressive
mode exchange. The default is off.
o IkeLifetimeSecs <integer>
Specify the lifetime in seconds of the Phase 1 IKE connection. The
default is 28,800 seconds.
o IkeReconnThresh <integer>
Specify the time limit in seconds after the IKE Lifetime expires when a
Phase 1 connection is re-keyed. The default is 20 seconds.
o Ph2DHGroup None | MODP-768 | MODP-1024 | MODP-1536
Specify the Diffie-Hellman group for Phase 2, used to generate the sym-
metric key for PFS:
∇ None (PFS is not used)
The size of the group determines the level of security of the Diffie-Hell-
man key exchange. (The higher the group number, the greater the secu-
rity.) The groups use traditional exponentiation over a prime modulus
data.
o EspTransformId ESP-DES | ESP-3DES | ESP-AES-128 |
ESP-AES-192 | ESP-AES-256
The encryption method used for Phase 2 to transform the payload data in
the packets from an intelligible form (plain text) into an unintelligible
form (cipher text), and back.

Specify the encryption algorithm to use for the ESP tunneled packets:
∇ ESP-DES: The Data Encryption Standard, defined by the U.S. gov-
ernment. DES is a symmetric 64-bit block cipher that uses a 56-bit
key.
∇ ESP-3DES: A variant of DES, and is the most accepted method.
3DES is a combined set of two DES keys totalling 112 bits. Due to its
larger size, 3DES is considered much more secure that DES.
∇ ESP-AES-128: AES (Advanced Encryption Standard) with a 128-bit
key.
∇ ESP-AES-192: AES with a 192-bit key.
o Ph2HashAlg MD5 | SHA-1
The hash authentication method used for Phase 2 to verify that the packets
being received were sent by the stated source. Specify the hash algorithm
to be used for the tunneled packets:
∇ MD5: A message-digest algorithm that derives a secure, irreversible,
than SHA-1.
∇ SHA-1: The Secure Hash Algorithm version one, part of the U.S.
secure.
o SaLdSecLife <integer>
Enter the Security Association (SA) lifetime in seconds for the estab-
lished tunnel. The default is 28,800 seconds.
o RekeyThreshSecs <integer>
Enter the time limit in seconds before the Security Association (SA) life-
time expires (SaLdSecLife parameter), when a re-key for Phase 2 is
started. The default is 30 seconds.
o IkeTimeout <integer>
Enter the time limit after which any Phase 1 or 2 messages will be trans-
mitted, in seconds.
o IkeRetries <integer>
Enter the maximum number of re-transmissions for any of the Phase 1
and Phase 2 messages. The default is 5.
o Ph2NumTunnels 1-per-Subnet | 1-per-Host
Specify the number of Phase 2 tunnels to open: one per subnet (site-to-site
tunnels) or one per host (remote access emulation). The default is 1-per-
Subnet.

o Ph2DestSubnet <X.X.X.X>
Specify the destination IPv4 subnet to which ESP packets will be sent.
This parameter only applies to a site-to-site tunnel.
o Ph2DestSubnetMask <X.X.X.X>
Specify the destination IPv4 subnet mask to which ESP packets will be
sent. This parameter only applies to a site-to-site tunnel.
o Ph2DestIPv6Prefix <Ipv6 IP>
Specify the destination IPv6 subnet to which ESP packets will be sent.
This parameter only applies to a site-to-site tunnel.
o Ph2DestIp6Mask <Ipv6 IP>
Specify the destination IPv6 subnet mask to which ESP packets will be
sent. This parameter only applies to a site-to-site tunnel.
o Ph2CommitBit on | off
Enable or disable the Phase 2 Commit bit. This bit ensures that the IPSec
tunnel has successfully completed the Phase 2 Quick mode exchange. The
default is off.
o RemoteNetworkVersion 4 | 6
Specify the IP version of the remote network. Possible values are 4 for
Ipv4 and 6 for Ipv6.
• Tunneling
Tunneling is a method for transmitting original data packets as payloads between
two nodes.
Subnet profile Tunneling attributes within the test configuration array should
WaSubnet,<SubnetProfileName>,Tunneling,<Tunneling Parame-
ter> <value>
◊ <Tunneling Parameter> <value>
o Gateway on | off
Enable or disable tunneling. The default is on.
o RemoteAccess on | off
Specify whether this is a site-to-site or remote-access tunnel. If on, the
tunnel is a remote-access tunnel. If off, the tunnel is a site-to-site tunnel.
The default is off.
o Persistent on | off
Specify whether the tunnel is persistent. The default is off (not persistent).
o GwIpVer 4 | 6
Specify the IP version of the gateways in a site-to-site tunnel. The default
is 4. For remote-access tunnels, use RemoteGwIPaddr.

o LocalGwMacAddr <XX:XX:XX:XX:XX:XX>
Enter the MAC address of the local gateway. This address is only used for
a site-to-site tunnel.
o LocalGwIpAddr <X.X.X.X>
Enter the IP address of the local gateway. This address is only used for
IPv4 addresses. (IPv6 addresses are derived from the MAC Address).
o RemoteGwIpAddr <X.X.X.X> | <IPv6 IP>
Enter the IP address of the remote gateway, the address to which the fire-
wall will establish the IPSec tunnel, in either IPv4 or IPv6 format. For
remote-access tunnels, use the LocalGwIPVer parameter instead.
• XAuth
IKE Extended Authentication (XAuth) is a protocol for authenticating user names
and passwords before the remote-access tunnel is opened.
Subnet profile XAuth attributes within the test configuration array should adhere
WaSubnet,<SubnetProfileName>,XAuth,<XAuth Parameter>
<value>
Note: You must provide the XAuth attributes only when the IPSec <AuthMeth>
attribute is set to XAuth.
◊ <XAuth Parameter> <value>

o UsernameWildcardBase <string>
Specify the string base from which the user names are generated when the
authentication mode is XAuth. Valid only at the client side. The default
string is User####.
o PasswordWildcardBase <string>
Specify the string base from which passwords are generated when the
authentication mode is XAuth. Valid only at the client side. The default
string is Password####.
o GroupName <string>
Specify the group name when the gateway is being used for multiple
users. Use this parameter only for IPv4 client subnets and when the
authentication mode is XAuth and set to Cisco EasyVPN. You must spec-
ify this parameter along with the GroupPassword parameter for the client
to interoperate with Cisco and Nortel IPSEC gateways using XAuth.

o GroupPassword <string>
Specify the password for the group specified in GroupName when the
authentication mode is XAuth. Use this parameter only for IPv4 client
subnets. You must specify this parameter along with the GroupName
parameter for the client to interoperate with Cisco and Nortel IPSEC gate-
ways using XAuth.
o Type Generic | Cisco-EasyVPN | Nortel-Contivity |
Checkpoint Hybrid
Specify the type of XAuth authentication to perform for Phase 1 for
remote-access tunnels. The default value is Generic.
o FormsDB on | off
Enable or disable including a forms database. The default is off.
o File <Forms Database Profile Name>
Specify the profile name of the forms database, which you created using
WaFormDatbase, to associate with the current subnet profile.
• ForcedPathMTU
Subnet profile Forced Path MTU (maximum transmission unit) attributes within
the test configuration array should adhere to the following syntax:
WaSubnet,<SubnetProfileName>,ForcedPathMTU,<MTU Parame-
ter> <value>
◊ <MTU Parameter> <value>
o Enabled on | off
Enable or disable this functionality. The default value is on.
o Size <integer>
Specify the size of the maximum transmission unit (MTU). The default is
1500 bytes.
• DHCP
The dynamic host configuration protocol (DHCP) is an Internet protocol for auto-
mating the configuration of computers that use TCP/IP. DHCP enables individual
computers on an IP network to get their configuration information from a DHCP
server.
Use the DHCP subnet profile to automatically assign IP addresses to the client’s
users from a DHCP server.

Subnet profile DHCP attributes within the test configuration array should adhere
WaSubnet,<SubnetProfileName>,Dhcp,<Dhcp Parameter><value>
◊ <Dhcp Parameter> <value>
o Enabled on | off
Enable or disable DHCP mode. The default value is off.
o Timeout <integer>
Specify the amount of time in milliseconds the client waits for a response
from the DHCP server. The default is 5000 milliseconds.
o Retries <integer>
Enter the number of times the client attempts to request an IP address
from the DHCP server. The default is 3.
o Number <integer>
Specify the number of IP addresses to get from DHCP server. The default
is 1.
• IPV6
Use the IPV6 subnet profile when configuring an IPv6 subnet.
Subnet profile DHCP attributes within the test configuration array should adhere
WaSubnet,<SubnetProfileName>,IPV6,<IPV6 Parameter><value>
◊ <IPV6 Parameter> <value>
o AssignPrefix on | off
Enable or disable the addition of a prefix (mask) for the Ipv6 subnet. The
default value is off. An IPv6 prefix indicates the fixed part of the address.
(As in IPv4 CIDR notation, this defines the network portion of the
address.) Specify an IPv6 address range using an IPv6 prefix address
(PrefixAddress)and prefix length (PrefixLength).
o PrefixAddress <IPv6 prefix>
Specify the IPv6 prefix address to use if you enabled the AssignPrefix
parameter. The default value is 3FFE::0. Use this parameter with <Pre-
fixLength> to specify the network part of an IPv6 subnet.
o PrefixLength <integer>
Specify the IPv6 prefix length in bits, from 16 to 128. The default value is
64. Use this parameter with <PrefixAddress> to specify the network
part of an IPv6 subnet.

o AddressRanges
Subnet profile AddressRanges attributes within the test configuration
array should adhere to the following syntax:
WaSubnet,<SubnetProfileName>,IPV6,Address-
Ranges,<Ranges Parameter><value>
∇ Specify two IPv6 addresses separated by a hypen (-) to indicate the
IPv6 address range. The default is 3FFE::0200:FF:FE00:1-
3FFE::0200:FF:FE00:FF.
o UseMacAddress on | off
Enable or disable the use of the MAC address range specified in the
<MacAddressRanges> parameter to generate the associated IPv6 address
range. The default value is off. If you do not want to use a MAC address
range, then you must specify the prefix address, prefix length, and address
range parameters for the IPv6 subnet.
WaUserProfile
Usage Use the User Profile parameters to define the type of user behavior to emulate.
Client User Profile parameters simulate the actions and behavior of users browsing an
Internet site. You can create multiple client (user) profiles for each test to simulate
different behaviors. For example, you can simulate users who visit your Internet site,
click on three to five links in rapid succession, and then leave. Then create another profile
that simulates users who visit your site and browse 10 or more separate pages for one
minute each.
These entries are equivalent to setting parameters in the Client Profiles tab of the Layer 4-
7 Application.
Syntax WaUserProfile,<UserProfileName>,<Parameter> <value>
• <UserProfileName>
Specify the name for this User Profile on the target device. This name is used to
Write a short sentence describing the user profile.
• Comment {<basic comment>}
Additional space to permit the user to place a comment.

• ThinkTime <integer>
The number of seconds that you want to wait between retrieving the last URL and
the next URL. A URL can contain two types of object references, a level-1 URL
for the Web page (1) and a level-2 URL for the Web page components (2). The
default is 0.
• BlastMode on | off
Enable or disable blast mode (see below). Use Blast mode to ignore the Think-
Time settings in both the user profile and action list.
Disable blast mode to ignore user Think time and URL level (1, 2) references, and
simulate random burst errors.
The GUI equivalent for the BlastMode option is the Disable User Think Time
checkbox on the Load tab for the Client.
• ClickAwayPercent
Enter the percentage of aborted transactions. Abort provides real-life traffic that
imposes extra load on servers that are processing logins and accessing data from a
database server. An abort is necessary because often user transaction history/status
would be left in a state that requires cleanup after an abort instead of a graceful
termination. The default is 0. The GUI equivalent for this parameter is the Time
Before Abort field on the Client Profiles tab.
• ClickAwaySeconds 0
Enter the number of seconds a simulated user waits before proceeding to the
next URL. For example, if a URL takes 10 seconds to retrieve and Abort is set to
100% at 8 seconds, the transfer will be aborted before completion. All embedded
objects of a page will be aborted if the URL happens to be the level 1 URL. The
default is 0. The GUI equivalent for this parameter is the Abort field on the Client
Profiles tab.
• FollowRedirects on | off
Enable to cause the client to pursue Moved Temporarily or Moved Permanently
responses. If you do not enable this option, the client records a 301 or 302 result
code in the CSV file instead of a successful transaction. (A successful transaction
means a result code of 200 OK is received, and data is completely received.). The
default is off.
• CloseConnectionAllowed on | off
Enable or disable connection closing as soon as possible. Enable to cause the
HTTP protocol engine to instruct the TCP stack to close connections (send FIN)
following receipt of a Connection: Close HTTP header.
If you don't enable this option, the application waits to receive a FIN from the
server before sending its own FIN. The client behavior more closely resembles
that of popular browsers, but runs the risk of leaving connections open for the
duration of the inactivity timer. The default is off.

• ReusePreloadedCookies on | off
Enable or disable the reuse of preloaded cookies. Enable to reuse preloaded
cookies in a subsequent test. The default is off.
• UseCookies on | off
Enable or disable the use of cookies. Cookies are preloaded from the cookie jar list
you specify in the CookieJarFile parameter. The default is on.
• CookieJarFile <cookie jar file>
Designate a server-specific Cookie Jar file for this client profile.
• BasicAuth on | off
Enable or disable basic authentication. Enable to allow simulated users to login
though authentication-enabled firewalls or IIS servers that have Basic
Authentication turned on. The client automatically hashes the username and
password into the HTTP header. The default is off.
• UserName <username>
Specify the login name for basic authentication.
• UserPassword <password>
Specify the login password for basic authentication.
• Persistence on | off
Enable or disable persistent connections under HTTP 1.1. You specify the protocol
level using the HttpProtocolLevel parameter (see page 82). When connections are
persistent, multiple requests can use the same connection to the proxy. The default
is on. If you specified HttpProtocolLevel = 2, you can enables or disable the Per-
sistence parameter under HTTP 1.1.
• KeepAlive on | off
Enable or disable the connection after the initial request is accepted, which pre-
vents the caches from establishing and tearing down a high number of connections
from a client. The default is on. You specify the protocol level using the HttpPro-
tocolLevel parameter (see page 82). If you specified HttpProtocolLevel = 1, you
can enable or disable the KeepAlive parameter under HTTP 1.0.
Note: Both HTTP/1.0 with KeepAlive enabled and HTTP/1.1 with Persistence
enabled simulate a user issuing multiple GETs to one server to retrieve multiple
objects using the same TCP connection. To use KeepAlive or Persistence, you
must have multiple URLs accessing the same server.
• Pipelining on | off
Enable or disable pipelining. The default is off.
• TransactionsPerConnection <integer>
Enter the number of transactions per connection. The default is 50.

• NumberOfSimultaneousConnections <integer>
Enter the number of instantaneous connections. The default is 2.
• SSLConfig
User profile SSLConfig attributes within the test configuration array should
WaUserProfile,<UserProfileName>,SSLConfig,
<SSLParameter> <value>
◊ <Parameter><value>
o SSLCipherIndex <certificate name>
Specify an SSL Certificate if you want to use one with your test.
o ReuseSessionID on | off
Enable or disable re-use of the session ID. Enable to simulate a user
attempting to use the same SSL Session ID that was initially negotiated
with the server for subsequent connections in the URL list. You can con-
figure the maximum TCP connections before re-negotiation, however, the
server might renegotiate before reaching that value. The default is on.
o TransactionsPerID <integer>
Enter the number of TCP connections that occur before ReuseSessionID
is activated. The default is 100. The GUI equivalent for this option is the
Connections Before Renegotiation field of the SSL Configuration fields.
o VerifyServer 0 | 1 | 2
Specify the required level of server authentication from the following
options:
0 – No certificate checking
1 – Valid certificate optional
2 – Valid certificate mandatory
The default is 0.
o CipherSuite
SSLConfig profile ciphersuite attributes within the test configuration
WaUserProfile,<UserProfileName>,SSLConfig,
CipherSuite,<Cipher Parameter> <value>

For <Cipher Parameter> <value>, specify one of the follow-

ing:
∇ Preload <blank> | IE5D | IE5E | NetscapeD |
NetscapeE - Specify the preloading of a set of Ciphers as used
by a common browser, or do not specify any to permit a custom
combination of ciphers:
IE5D – Emulates using Internet Explorer 5 with Domestic Ciphers

IE5E – Emulates using Internet Explorer 5 with Export Ciphers
NetscapeD – Emulates using Netscape 4 with Domestic Ciphers
NetscapeE – Emulates using Netscape 4 with Export Ciphers
∇ Cipher {<Cipher1> <Cipher2> <Cipher3>} - Specify a
list of ciphers to use. The input format is similar to a standard Tcl list;
enclose items within curly braces and separate items with a space.
o SendCloseNotify on | off
Enable or disable close notification. Enable to notify the recipient that the
sender will not send any more messages on this connection. The default is
off.
o EnableCommonNameMatching on | off
Enable or disable common name matching, which means that the URL by
which the site is accessed must match the Common Name. (The Common
Name is the name of the Web site for which the SSL certificate was
issued.) The default is off.
o Versions {SSLv2 SSLv3 TLSv1}
Specify the version(s) of SSL that you want to emulate. The input format
is similar to a standard Tcl list; enclose items within curly braces and
separate items with a space. The default value is SSLv2.
o UserCertificate <user certificate file path>
Specify the location of the user certificate file to be incorporated within
the test, for example, {c:\\Certs\\user.pem}.
• NacProfile
User profile NacProfile attributes within the test configuration array should adhere
WaUserProfile,<UserProfileName>,NacProfile,
<Nac Parameter> <value>
◊ <Nac Parameter> <value>
Specify the following:
o Enabled yes | no
Enable or disable the NAC profile described within this user profile. The
default is no.

o Plugin
NacProfile Plugin parameters within the test configuration array should
WaUserProfile,<UserProfileName>,NacProfile,Plu-
gin,<PluginId>,<Nac Parameter> <value>
∇ PluginId iterates with each new Plugin definition within the cur-
rent <UserProfileName> from 0 onwards.
For <Nac Parameter> <value>, specify the following:
∇ Code <integer>
A Posture Plugin (PP) provides posture credentials to a posture agent
residing on the same device. Specify the Plugin code:
1—Cisco Posture Agent Plugin
2—Cisco Host Plugin
3—Cisco Anti-Virus Plugin
4—Cisco Firewall Plugin
5—Cisco Host Intrusion Protection Service (HIPS) Plugin
32768-65535—Reserved for custom plugins
∇ Name AV | FW | HIPS | Host | PA | Other
Specify the name that corresponds to the Plugin code:
AV (Cisco Anti-Virus Plugin)
FW (Cisco Firewall Plugin)
HIPS (Cisco Host Intrusion Protection Service (HIPS) Plugin)
Host (Cisco Host Plugin)
PA (Cisco Posture Agent Plugin)
Other—Custom plugin
∇ Vid <integer>
The vendor application's ID. This ID is the vendor's SMI Network
Management Private Enterprise Code. The IANA (International
Assigned Numbers Authority) maintains the official list of enterprise
codes. Standard RADIUS attributes are associated with an ID of 0.
Specify the vendor ID:
9—Cisco
311—Microsoft
0-99999—Other vendor IDs (excluding 9 and 311)

∇ Attribute
NacProfile Attribute parameters within the test configuration array
WaUserProfile,<UserProfileName>,NacProfile,Plu-
gin,<PluginId>,
Attribute,<AttributeId>,<Attribute Parameter>
<value>
∇ AttributeID iterates with each new attribute definition within the
current Plugin definition from 0 onwards.
For <Attribute Parameter> <value>, specify the following:
∇ Id <integer>
Specify the attribute's ID. This field, in combination with the vendor
ID, uniquely identifies an AVP (attribute-value pair). Valid values are
3, 4, 5, 9, 10, or 32768-65535.
∇ Name <string>
Specify the attribute's display name.
∇ Value
Specify the associated vendor-specific attribute value. This value
should be consistent with the Format that you specify.
∇ Format <integer>
Specify the attribute's format type (1-8) as follows:
1 = String
2 = UInt32
3 = MAC
4 = IPv4
5 = IPv6
6 = Binary
7 = Date MM/DD/YYYY HH:MM:SS
8 = Version X.X.X.X
The default is 1 (String).
• UrlList <urllist name>
Specify the name of a URL List.
Note: In the Layer 4-7 Application, you can associate a user profile and one or
more URL action lists to a subnet. However, in the client, you can associate only
one user profile to one URL action list. In the client, you must create a copy of the
user profile each time you want to use that user profile with a different URL list.

• UseFormData on | off
Enable or disable the use of the form database. Use a form data file to create URL
lists that simulate users submitting POST requests to an Internet site. Basically,
you can have a list of any variables that you want to cycle through from the URL
list. For example, you might want to create a file of user names and passwords.
The default is off.
• ProxyAuth on | off
Enable or disable proxy authentication. Enable to allow simulated users to log 92
in though authentication proxy servers. The client automatically hashes the
username and password into the HTTP header. The default is off.
• ProxyUserName <username>
Specify the login name for proxy authentication.
• ProxyUserPassword <password>
Specify the login password for proxy authentication.
• MaxConnectionsPerCawUser <integer>
Specify the maximum number of connections per simulated user. The minimum
value is 1, the maximum is 65535. The default is 1.
• VerifyMD5DigestHeader on | off
Enable or disable MD5 Digest Header verification. Select to verify that the entire
entity body was received correctly. This option only applies to the HTTP protocol,
and is disabled by default. You can use it with any Internet server that sends a
Content-MD5 header.
• HttpProtocolLevel 1 | 2
Specify the HTTP Protocol Level.: 1 equals HTTP/1.0, and 2 equals HTTP/1.1.
The default is 2.
• UserAgent <user agent>
Enter a description of a simulated client’s vendor, version, and so on
• ExtendedHttpHeaders {<headerline> <headerline2>
<headerline3>}
Specify additional HTTP headers. Enter information to manually customize HTTP
headers for each Client profile. Common uses include more file type support,
Pragma: No-Cache to bypass caches, manual insertion of cookies, support for
access of User and Session IDs from a forms database with up to one million rows,
and the ability to apply variables to the HTTP header. The input format is similar
to a standard Tcl list; enclose items within curly braces and separate items with a
space
• StreamingHttpPort <integer>
Enter a port number to use while streaming if <StreamingTransport> is set to
HTTP. The default port number is 80.

• StreamingTransport udp | tcp | http

Specify the streaming transport protocol:
◊ UDP: Control connection over TCP, data transmission over UDP
◊ TCP: Set up over TCP, data transmission over TCP
◊ HTTP: Set up over HTTP, data transmission over HTTP. If you select this
option, enter a port number for <StreamingHttpPort>. The default port
number is 80.
The default is udp.
• StreamingUserAgent <string>
A streaming media player has a user-agent header that identifies the player type,
such as those for QuickTime, Windows Media, and RealMedia. Including the user
agent allows you to more realistically reproduce your own traffic patterns, and
allows for more thorough testing of the streaming server infrastructure and devices
under test.
Enter the name of the streaming user agent. The default is an empty string.
• UseStreamingProxy true | false
Enable this option if you want to establish a connection with a streaming proxy (or
cache engine). The cache engine establishes a connection with the server, and the
server returns refreshed content. The default is false.
• StreamingProxyIP <X.X.X.X>
IP address where the streaming proxy (or cache engine) is listening for streaming
requests. The default is an empty string.
• StreamingProxyPort <integer>
Port where the streaming proxy (or cache engine) is listening for streaming
requests. The default is 0.
• DecompressGzip on | off
Enable this option if you want the client to accept gzip compressed data and then
decompress the data so that you can review it, such as when you use search,
match, or match not in an action list. If you enable this option, you must enter an
associated action in your action list that accepts the data and deflates it. The
default is off.
• EnforceContentLength on | off
Enable this option if you want a transaction to be considered as failed if the length
of the data content received in an HTTP response is less than the value specified in
the content-length HTTP header. The default is on. If you disable this option, and
the value is incorrect, the transaction will be marked as successful.
Regardless of whether this option is enabled or disabled, if length of the content
received is less than what was specified, then the Bad Content Length field in
HTTP statistics is incremented.

This option is effective only if the TCP connection is closed by the server or
closed by TCP inactivity timeout.
• ForceProxyAuth on | off
Enable this option so that the first request to the proxy server sends the username
and password. If you disable this option, the client waits for a "Proxy
Authorization Required" message from the proxy to send the credentials over on
the subsequent request. The default is off.
• DbFiles on | off
To complement URL lists (also known as action lists), you can use form data files
to provide values that simulate simultaneous Internet users entering data to access
an Internet site. Form data files allow lists to query values similar to a database,
instead of placing all the data in the list. Form data files are supported for the
following protocols and the data indicated:
HTTP—Supports IP addresses (supported by using APPLY), custom HTTP
headers, and HTTP Post file content. Also support the value of a key/value pair.
HTTPS—Supports IP addresses (supported by using APPLY).
POP3—Supports user name and password fields.
SMTP—Supports From, To, and Subject fields.
Telnet—Supports EXPECT and SEND commands within Telnet protocols for the
client side only.
• LoadProfile <LoadProfile name>
Enter the name of the user-based Load profile.
• LocalSIPPort <integer>
Enter the port number on which the SIP listener will be created. The default port is
5060.
• RTPFirstPort <integer>
Enter the port number on which the first Real-time Transport Protocol (RTP) lis-
teners will be created. The value should be even and in the acceptable port range.
The port value is incremented by 2 for each additional RTP channel. The default
port is 10000.
• NumOfRTPListeners <integer>
Enter the number of RTP channels that will be created. The default is 50.
Note: In the current release, the number of channels can be less than the maximum
number of simultaneous calls, since the channel can be reused by different calls.
However, this may be changed in a future release. It is recommended that you set the
number of channels to be greater than the expected maximum number of
simultaneous calls to provide more realistic traffic.

• UseDNSHostFile <integer>
Enable or disable the use of a DNS host file. If you enable the DNS Host File fea-
ture, you must also specify the DNS host file to use in the DNSHostFile parame-
ter. Enabling and creating a DNS host file permits you to specify a host name
within the URL list, instead of an IP address. (See WaUrlList for more informa-
tion.) The client will then use the host profile to map the specified host name to its
IP address. The default is false.
• DNSHostFile <string>
Enter the name of the DNS host file to use with the UseDNSHostFile parameter.
• DnsRetries <integer>
Specify the number of times a DNS query will be retried by the client. This num-
ber includes the first query attempt. The default is 3.
• DnsFirstRetryInterval <integer>
Specify the amount of time, in milliseconds, that the client waits before retrying
the DNS query after the initial query. This time only applies to the first interval
between query retries. The default is 3000.
• DnsOtherRetryInterval <integer>
Specify the amount of time, in milliseconds, that the client waits before retrying
the second and all subsequent query retries. The default is 3000.
• FollowMetaRefresh on | off
Enable this parameter to emulate how a browser behaves when following meta
refreshes. Each page returned to the client from the server is parsed for a string
similar to the following:
<META HTTP-EQUIV="refresh" CONTENT="1; URL=http://192.168.44.16/
index6.html">
Or
<META HTTP-EQUIV="refresh" CONTENT="1; URL=/path/a/b/c/
page.html">
Or
<META HTTP-EQUIV="refresh" CONTENT="1">
If the client finds one of the previous strings, it is either redirected to the new
remote host, the same host with a different path, or to the same host and same path,
respectively. If redirected to a page that contains another redirect, the client can
follow a maximum sequence of 10 redirects. The default is off.
Note: The API automatically enables the FollowRedirects parameter (see page
76) when you enable the FollowMetaRefresh parameter.
Use the following MM4 parameters to define information to emulate an originator MMS
Relay/server, simulating the forwarding of MM4 messages to another MMS Relay/Server.
Each MM4 message is sent by using a separate SMTP session on the client and server.

• Mm4OriginatorPort <integer>
Specify the client port number that accepts MM4 messages from the server. The
default is the SMTP port, 25. The port you specify here must be the same port
specified in the OriginatorPort parameter in the MM4.
• Mm4ResponseTimeout <integer>
Specify the amount of time in milliseconds the client waits for an MM4 response
from the server. Make sure that the value you enter here is less than the timeout
you set for the Mm4SessionTimeout parameter. The default is 1000 millisec-
onds.
• Mm4SessionTimeout <integer>
Specify the amount of time in milliseconds the client waits for the end of an MM4
session. A session includes all of the transactions that take place in the MM4
action. For example, if you request three responses from the server, then those
responses are part of the session. Make sure that the session timeout allows
enough time to complete all transaction responses. The default is 5000 millisec-
onds.
• Mm4SystemAddress <email address>
Specify the system email address of the originator Multimedia Messaging Service
Center (MMSC). The default system email address is origina-
[email protected].
• RadiusProfile
The Radius profile describes the RADIUS (Remote Authentication Dial In User
Service) accounting protocol, which is a protocol for carrying accounting informa-
tion between a Network Access Server and a shared Accounting Server. It is used
for authentication and authorization.
User profile RadiusProfile attributes within the test configuration array should
WaUserProfile,<UserProfileName>,RadiusProfile,
<RadiusParameter> <value>
◊ <RadiusParameter> <value>
Specify the following:
o AccountingEnabled on | off
Enable or disable RADIUS accounting traffic on the corresponding UDP
port. The default is on.
o UDPRetransmitCount <integer>
Specify the maximum number of times an un-acknowledged RADIUS
packet may be retransmitted. The default is 10.
o UDPRetransmitInterval <integer>
Specify the time in milliseconds upon expiration of which the Authentica-
tor must retransmit the RADIUS packet, except when the packet was
already acknowledged by the Authentication Server. The default is 2000.

o SSID <string>
Optionally, specify the Service Set Identifier (SSID), the network name
that identifies the area covered by one or more Access Points (802.11
technologies).
o Attribute
RadiusProfile Attribute parameters within the test configuration array
WaUserProfile,<UserProfileName>,RadiusProfile,
Attribute,<AttributeId>,<Attribute Parameter>
<value>
∇ AttributeID iterates with each new attribute definition within the
current <UserProfileName> from 0 onwards.
For <Attribute Parameter> <value>, specify the following:
∇ Vendor Cisco | Microsoft | Radius | Other
Specify the vendor type:
Cisco
Microsoft
Radius
Other
∇ Id <integer>
Specify the attribute's ID as an integer between 0 and 255. This field,
in combination with the Vendor, uniquely identifies an AVP
(attribute-value pair). The default is 0.
∇ Code <integer>
Specify the vendor code as an integer between 0 and 999. Use this
parameter only when the Vendor parameter is set to “Other.”
∇ Conform yes | no
Enable or disable whether the processing of the RADIUS attribute
must conform to RFC 2865/2866. Per these RFCs, only one byte is
allocated to store the length of the attribute's value, which means the
maximum possible length of the value is 255 bytes. In many cases,
vendors require the value's length to be larger than 255 bytes, in
which case you can disable RFC conformance. The default is yes.
∇ Category Authentication | Accounting
Specify whether the RADIUS attribute will use RADIUS authentica-
tion traffic or RADIUS accounting traffic. The default is authentica-
tion.
∇ Value
Specify the associated RADIUS attribute value. This value should be
consistent with the Format that you specify.

∇ Format <integer>
Specify the attribute's format type (1-7) as follows:
1 = String
2 = UInt32
3 = MAC
4 = IPv4
5 = IPv6
6 = MTU
7 = Binary
The default is 1 (String).
• BrowserPreload Firefox 1.0.3 | Firefox 1.0.4 | Ms internet
explorer 5.x | Ms internet explorer 6.x | Netscape naviga-
tor 4.x | Netscape navigator 7.1 | Netscape navigator 7.2
| Netscape navigator 8.x | Opera 8
Specify the inclusion of a specific set of browser presets within the current profile.
There is no default browser. You must specify one.
Note: GUI Equivalent: Profiles Tab, Browser Emulation - 'Preload Values From'
• ForceBrowserPreload yes | no
Enable or disable the forcing of a specific set of browser presets over any user
modified values directly affected by the browser presets. For example, specifying
a <BrowserPreload> value of “Opera 8” will auto-populate the following parame-
ters: <UserAgent>, <ExtendedHttpHeaders>, <HttpProtocolLevel>, <Persis-
tence> & <NumberofSimultaneousConnections>.
If you specify a separate <Persistence> value, then setting <ForceBrowserPre-
load> to “no” results in the use of the user-specified <Persistence> value. Specify-
ing <ForceBrowserPreload> as “yes” results in the <Persistence> value associated
with the <BrowserPreload> selection to be used.
The default is no.
WaUrlList
Usage Use the UrlList parameters to create a URL list that includes the URLs targeted during a
test. If you use host names or fully qualified domains, make sure that a valid DNS server is
accessible from the administration interface.
URL lists identify the actions that the client takes for each simulated user during a test.
Each URL list line represents a simulated user requesting an object from your test server.
These entries are equivalent to creating an action list in the Client Actions tab of the Layer
4-7 Application.

Syntax WaUrlList,<URLListFilename>,<URL Entry Number> <value>

Example: WaUrlList, $waUrlList0Name,0 {http://192.168.42.11/
?Transaction-Profile_cawlMconnections}
• <URLListFilename>
Specify a name for the URL list to create.
• <URL Entry Number> <value>
Iterates with each new URL definition within the current <URLListFilename> from
0 onward.
• URL Entry {<URL Entry>}
Each URL entry is equivalent to one single line within a typical URL List, for
example, {1 GET http://192.168.42.11}
If your URL entry contains the dollar sign ($) character, you must escape
this character via a backslash as follows: \$. If you do not, the Tcl interpreter will
interpret the dollar sign ($) character as being the start of a Tcl variable name. For
example:
GUI:
{1 http://200.40.1.105 <AUTH:BASIC USER=users.$1
PASSWD=users.$2>}
API:
{1 http://200.40.1.105 <AUTH:BASIC USER=users.\$1
PASSWD=users.\$2>}
WaStaticRouteTable
Usage Use the static routing table profile parameters to create a static routing XML configuration
file for a routed network.
Syntax WaStaticRouteTable,<StaticRouteFilename>,Route,<RouteNumber>,
<Parameter> <value>
• <StaticRouteFilename>
Name of the static routing XML configuration file that will be created.
• <RouteNumber>
Iterates with each new routing table entry from 0 onwards.

Enter the address of the network for which this routing applies.
• NetMaskBits <integer>
Enter the number of bits in the specified network that comprise the network part of
the address. The default value is 24.
• GatewayAddress <X.X.X.X>
Enter the address of the gateway to which you send packets destined for the speci-
fied network.
WaTelnetProfile
Usage Telnet profile entries within the test configuration array.
Syntax WaTelnetProfile,<TelnetProfileName>,Telnet,<Parameter> <value>
• <TelnetProfileName>
Specify the name for this Telnet Profile on the target device. This name is used to
• options on | off
Enable or disable Open Negotiation. Enable to notify the server that before using a
Telnet option, the parties must negotiate to ensure that both ends support the
option. The default is on.
• endOfLineChar none | CR | CR/LF
Indicate if you want to add end-of-line characters to each Telnet command:
None – No end-of-line character
CR – Carriage Return
CR/LF – Carriage Return and Line Feed
The default is None. The GUI equivalent for this parameter is the End of Live
Sequence to Send field in the Telnet Client Information fields of the Client Profiles
tab.

• Command
Telnet profile Command parameter entries within the test configuration array
WaTelnetProfile,<TelnetProfileName>,Telnet,Command,<Com-
mand Entry Number>,<Command Parameter> <value>
◊ <Command Entry Number>
Iterates with each new Command definition within the current
<TelnetProfileName> from 0 onwards.
◊ <Command Parameter> <value>
o send <command>
Specify the command that you want to send. In the Send and Expect
parameters, you can specify strings that contain unprintable characters,
such as carriage return, line feed, backspace, tab, and so on. You must use
URL-style escaping to encode these characters in the form of %xx, where
xx is the characters hexadecimal code. For example, line feed is escaped
as %0D, backspace is escaped as %08, and so on.
o expect <command>
Specify the Expect command.
o close none | do | expect
The close command that you specify at the end of the session should be
“do” on the client side, and “expect” on the server side, or vice-versa.
Specify the type of close command to be either none, do, or expect.
o timeout <integer>
Enter the time to wait after the send command.
o wait <integer>
Enter the time to wait after the expect command.
o echooff on | off
Enable or disable mode of terminals echo.
• ClientCommand
Telnet profile ClientCommand parameter entries within the test configuration
WaTelnetProfile,<TelnetProfileName>,Telnet,ClientCommand,
<Client Command Entry Number>,<Client Command Parameter>
<value>
◊ <Client Command Entry Number>
<TelnetProfileName> from 0 onwards.

◊ <Client Command Parameter> <value>

o send <command>
Specify the command that you want to send. In the Send and Expect
parameters, you can specify strings that contain unprintable characters,
such as carriage return, line feed, backspace, tab, and so on. You must use
URL-style escaping to encode these characters in the form of %xx, where
xx is the characters hexadecimal code. For example, line feed is escaped
as %0D, backspace is escaped as %08, and so on.
o expect <command>
Specify the Expect command.
o close none | do | expect
The close command that you specify at the end of the session should be
do on the client side, and expect on the server side, or vice-versa. Specify
the type of close command to be either none, do, or expect.
o timeout <integer>
Enter the time to wait after the send command.
o wait <integer>
Enter the time to wait after the expect command.
o echooff on | off
Enable or disable mode of terminals echo.
WaPPPGroupProfile
Usage Use the PPPGroupProfile entries within the test configuration array to configure Point-to-
Point Protocol (PPP) parameters. The client supports the following capabilities:
• LCP negotiation
• IPCP negotiation for link establishment for network layers
• Authentication protocols: PAP, CHAP, or None (device under test initiates)
• LCP Echo request/response
• Magic number specification.
Syntax WaPPPGroupProfile,<PPPProfileName>,<Parameter> <value>
• <PPPProfileName>
Specify the name for this PPP Profile on the target device. This name is used to

• MRU <integer>
The size of the Maximum Receive Unit (MRU). The default is 1492.
• MaxConfigReq <integer>
The number of times the client sends a Configure Request message without receiv-
ing a response. The default is 3.
• MaxConfigNak <integer>
Number of times an incorrect Configure Request from the device under test (DUT)
is NACKed before it is ignored. The default is 3.
• MaxTermReq <integer>
Number of times the client sends a PPP session termination message without
receiving a valid acknowledgement. The default is 3.
• RestartTimer <integer>
Time in seconds between Configure Request messages. The default is 3.
• MaxLinkRetry <integer>
Number of retry attempts if negotiation of the link fails. The default is 3.
• SessionTimeout <integer>
Inactivity timeout for the PPP session. The default is 0.
• UsersPerSession <integer>
Number of simulated users per PPP session. The default is 1.
• EchoInterval 10 <integer>
Frequency in seconds to send LCP keep-alive requests. The default is 10.
• EchoRequest on | off
Enable or disable the sending of LCP keep-alive requests. The default is off.
• EchoReply on | off
Enable of disable the responses to echo requests. The default is off.
• IPNegot on | off
Enable or disable IP negotiation. If enabled, the client uses IPCP to obtain the IP
address from the device under test (DUT). If disabled, the client uses the IP
address range established in the Client Subnet Profile parameters. Regardless
whether this option is enabled or disabled, you must specify a value for the
<IPAddressRange> parameter of the Client Subnet Profile parameters. The client
uses this information to specify the number of hosts that are in the test. The default
is on.
• MagicNbr on | off
Enable or disable the automatic generation of magic number. The default is off.

• TwoWayAuth on | off
Applies to Password Authentication Protocol (PAP) and Challenge-Handshake
Authentication Protocol (CHAP) authentication. Enables authentication in both
directions simultaneously. That is, the client authenticates with the Access
Concentrator (AC) using a username/password, and the AC authenticates with the
client using a username/password. The client automatically accepts the username/
password supplied by the AC.
If you do not enable this option, then the client performs only client
authentication with the Access Concentrator (AC). The default is off.
• UseAuthDB on | off
Enable of disable the authentication option. The default is on.
• AuthType None | PAP | CHAP
Specify the type of authentication. The default is PAP.
None – No authentication is performed
PAP – Password Authentication Protocol
CHAP – Challenge-Handshake Authentication Protocol
• DBFilename <DB Filename>
Use a database file to specify outgoing usernames and passwords.
• WildcardParams
PPP profile WildcardParams attributes within the test configuration array should
WaPPPGroupParams,<WaPPPGroupProfileName>,
WildcardParams,<Wildcard parameter><value>
◊ <Wildcard parameter> <value)
o WildcardUsername <Username>
Wild card username, such as user#.
o WildcardPassword <Password>
The wildcard password, such as pwd#.
o StartCountInnerLoop <integer>
Starting value of the first (inner) counter. The default is 0.
o EndCountInnerLoop <integer>
Ending value of the first (inner) counter. The default is 0.
o IncCountInnerLoop <integer>
Value by which the first (inner) counter is incremented. The default is 0.
o StartCountOuterLoop <integer>
Starting value of the second (outer) counter. The default is 0.

o EndCountOuterLoop <integer>
Ending value of the second (outer) counter. The default is 0.
o IncCountOuterLoop <integer>
Value by which the second (outer) counter is incremented. The default
is 0.
o IncSecondCount on | off
Enable or disable the second (outer) counter. The default is off.
WaPPPoEGroupParams
Usage Use the Client PPPoE entries within the test configuration array to configure additional
PPP parameters required for the Point-to-Point over Ethernet (PPPoE) Protocol.
Syntax WaPPPoEGroupParams,<PPPoEProfileName>,<parameter> <value>
• <PPPoEProfileName>
The name for this PPPoE Profile on the target device. This name is used to reference
this profile from within other profiles.
• <parameter> <value>
• TxRxInterval <integer>
The retry interval timer for PPPoE-related messages. The default is 3.
• MaxRetry <integer>
The number of times to retry PADI and PADR packets. The default is 3.
• ServiceName <Service Name>
The requested service type (string).
• ACName <AC Name>
An Access Concentrator (AC) tag to match against, in case multiple responses to
PADI packets are received.
WaDDOSConfig
Usage DDoS attack entries within the test configuration array fall into two categories. The first
pertains to global attack variables which are applied to all attacks on all ports. The second
encompasses variables which are unique to a given type of attack. The global attack
variables are covered first, followed by individual attacks and their specific variables.
Syntax WaDDOSConfig,<DDOSConfigFilename>,<Parameter> <value>

• <DDOSConfigFilename>
The name to assign the file in which your DDOS configuration information is stored.
This information describes the traffic pattern that is generated. DDOS information is
specific to a test.
• StartingSourceMACAddress <X:X:X:X:X:X>
Source Ethernet address of the first generated packet. The default is
05:00:00:00:00:01.
• StartingDestMACAddress <X:X:X:X:X:X>
Destination Ethernet address of the first generated packet. The default is
0D:00:00:00:00:01.
• StartingSourceIPAddress <X.X.X.X>
Source IP address of the first generated packet. The default is 192.168.10.1
• StartingDestIPAddress <X.X.X.X>
Destination IP address of the first generated packet. The default is 10.1.1.1
• GlobalStartDelay <integer>
Delay in milliseconds between the start of the test (specifically, the beginning of
its Steady State) and when DDoS attacks begin. The default is 20000.
• Arp Flood Profile Parameters
An ARPFlood attack generates ARP (Address Resolution Protocol) packets
targeted at a specific network device from a range of virtual source addresses. The
type of ARP packets generated (that is, ARP Request/ARP Reply) is configurable.
ARPFlood attacks attempt to exploit limitations in the ARP handling/caching
capabilities of target networks and network devices
Arp Flood attack profile entries within the test configuration array should adhere
WaDDOSAttack,<TestFileName>,ARPFlood,
<ARPFlood Parameter> <value>
◊ <ARPFlood Parameter> <value>
o RepeatCount <integer>
The number of times to repeat the attack sequence. The default is 120.
o PacketsToGenerate <integer>
The number of packets to generate within each attack sequence. The
default is 1000.

o PacketRate <integer>
The packet generation rate in packets per second. The default is 1000.
o ARPHeaderSourceEthernetAddress <X:X:X:X:X:X>
The starting spoofed ARP header source Ethernet address. The default is
0A:05:00:00:00:01.
o ARPHeaderDestEthernetAddress <X:X:X:X:X:X>
The ARP header destination Ethernet address of the target. The default is
0A:05:00:00:00:01.
o ARPHeaderSourceIPAddress <X.X.X.X>
The starting spoofed ARP header source IP address. The default is
10.5.0.1.
o ARPHeaderDestIPAddress <X.X.X.X>
The ARP header destination IP address of the target. The default is
10.13.0.1.
o ARPHeaderOperation <integer>
The ARP header operation code. The default is 2.
o LocalStartDelay <integer>
An optional delay in milliseconds between the end of the delay specified
in GlobalStartDelay and when this attack begins. The default is 0.
• Evasive UDP Profile Parameters
An EvasiveUDP attack generates a stream of UDP frames with variable frame
sizes and random source IP addresses. Such frames cause disruption to the target,
especially at very high rates.
Evasive UDP attack profile entries within the test configuration array should
WaDDOSAttack,<TestFileName>,EvasiveUDP,
<EvasiveUDP Parameter> <value>
◊ <EvasiveUDP Parameter> <value>
default is 1000.
o UDPSourcePort <integer>
The number of the UDP header source port. The default is 1024.

o UDPDestPort <integer>
The number of the UDP header destination port. The default is 512.
An optional delay in milliseconds between the end of the
GlobalStartDelay and when this attack begins. The default is 0.
• Land Profile Parameters
Land attack sends TCP packets with the source IP address and source port number
identical to the target victim’s IP address and port number. This causes the
attacked host to think that it is speaking to itself and will often cause it to crash.
Land attack profile entries within the test configuration array should adhere to the
following syntax:
WaDDOSAttack,<TestFileName>,Land,<Land Parameter> <value>
◊ <Land Parameter> <value>
default is 1000.
o TCPDestPort <integer>
The TCP port number for both the source and destination. The default
is 80.
• Ping of Death Profile Parameters
A PingOfDeath attack sends IP packets of a size greater than 65,535 bytes to the
target computer. IP packets of this size are illegal, but applications can be built that
are capable of creating them.
Important: This attack generates 47 packets per loop. Take this into consideration when
you specify the amount of load to generate.
Ping of Death attack profile entries within the test configuration array should
WaDDOSAttack,<TestFileName>,PingOfDeath,<POD Parameter>
<value>

◊ <POD Parameter> <value>

default is 1000.
• Ping Sweep Profile Parameters
A PingSweep attack generates ICMP (Internet Control Message Protocol) ping
request packets targeted at a range of destination addresses. A PingSweep attack is
typically used to identify the availability of network devices over a range of
addresses.
Ping Sweep attack profile entries within the test configuration array should adhere
WaDDOSAttack,<TestFileName>,PingSweep,
<PingSweep Parameter> <value>
◊ <PingSweep Parameter> <value>
default is 1000.
o PacketRate 1000 <integer>
o LocalStartDelay 0 <integer>
• Random Unreachable Host Profile Parameters
A RandomUnreachableHost attack sends ICMP ping request packets to random
systems with the goal of tying it up and causing it to drop connections. This type
of attack can paralyze a system, even if the packets are sent at very low rates.

Random Unreachable Host attack profile entries within the test configuration array
WaDDOSAttack,<TestFileName>,RandomUnreachableHost,
<RUH Parameter> <value>
◊ <RUH Parameter> <value>
default is 1000.
• Reset Flood Profile Parameters
A ResetFlood attack generates a sequence of TCP RST (Reset) packets targeted at
a range of destination addresses. A ResetFlood attack can be used to terminate
active (real) TCP connections on target networks and network devices.
Reset Flood attack profile entries within the test configuration array should adhere
WaDDOSAttack,<TestFileName>,ResetFlood,
<ResetFlood Parameter> <value>
◊ <ResetFlood Parameter> <value>
default is 1000.
o TCPSourcePort <integer>
The TCP port number for the source. The default is 1024.
The TCP port number for the destination. The default is 80.
• Smurf Profile Parameters
A Smurf attack generates ICMP (Internet Control Message Protocol) ping requests
to a specific network device from a range of virtual source addresses. A Smurf
attack is typically used to flood a network with traffic by sending ICMP ping
requests to broadcast addresses. On some networks, this can result in a flood of
ping responses generated and sent from all devices on the network.
Smurf attack profile entries within the test configuration array should adhere to the
following syntax:
WaDDOSAttack,<TestFileName>,Smurf,<Smurf Parameter>
<value>
◊ <Smurf Parameter> <value>
default is 1000.
o PacketRate 1000 <integer>
• Syn Flood Profile Parameters
A SynFlood attack generates a sequence of TCP SYN packets targeted at a
specific network device from a range of virtual source addresses. A SynFlood
attack can be used to overwhelm the ability of networks and network devices to
establish new TCP connections. SynFlood attacks can also be used to deplete the
resources (that is, system memory) of target networks and network devices.
Syn Flood attack profile entries within the test configuration array should adhere
WaDDOSAttack,<TestFileName>,SynFlood,
<SynFlood Parameter> <value>
◊ <SynFlood Parameter> <value>
The number of packets to generate each attack sequence. The default is
1000.
The TCP header source port number. The default is 1024.
The TCP header destination port number. The default is 80.
• TCP Port Scan Profile Parameters
A TCPPortScan attack generates a sequence of TCP SYN packets across a range
of TCP destination ports, for a range of target addresses. A TCPPortScan is
typically used to identify TCP ports on which TCP services are available. It can
also be used to overwhelm the ability of networks and network devices to establish
new TCP connections. TCPPortScan attacks can also be used to deplete the
TCP Port Scan attack profile entries within the test configuration array should
WaDDOSAttack,<TestFileName>,TCPPortScan,
<TCPPS Parameter> <value>
◊ <TCPPS Parameter> <value>
o TargetsToHit <integer>
The number of target addresses to scan. The default is 1.
o PortsToScan <integer>
The number of ports to scan on each target. The default is 65535.
The TCP header source port number. The default is 1024.
o StartingTCPDestPort <integer>
The first TCP header destination port number to scan. The default is 0.
• Teardrop Profile Parameters

A Teardrop attack sends fragmented messages that are deliberately constructed to
overlap. The target system is unable to reconstruct the messages.
Teardrop attack profile entries within the test configuration array should adhere to
the following syntax:
WaDDOSAttack,<TestFileName>,ResetFlood,
<ResetFlood Parameter> <value>
◊ <ResetFlood Parameter> <value>
default is 1000.
The number of the UDP header source port. The default is 1024.
The number of the UDP header destination port. The default is 512.
• UDP Flood Profile Parameters
A UDPFlood attack generates a sequence of UDP data packets targeted at a
specific network device from a range of virtual source addresses. A UDPFlood can
be used to consume network bandwidth and overwhelm the ability of networks
and network devices to establish new UDP connections. UDPPortScan attacks can
also be used to deplete the resources (that is, system memory) of target networks
and network devices.
UDP Flood attack profile entries within the test configuration array should adhere
WaDDOSConfig,<TestFileName>,UDPFlood,<UDPFlood Parame-
ter> <value>
◊ <UDPFlood Parameter> <value>
default is 255.
The UDP header source port number. The default is 1024.
The UDP header destination port number. The default is 512.
• UDP Port Scan Profile Parameters
A UDPPortScan attack generates a sequence of UDP data packets across a range
of UDP destination ports, for a range of target addresses. A UDPPortScan is
typically used to identify UDP ports on which UDP services are available. It can
also be used to overwhelm the ability of networks and network devices to establish
new UDP connections. UDPPortScan attacks can also be used to deplete the
UDP Port Scan attack profile entries within the test configuration array should
WaDDOSAttack,<TestFileName>,UDPPortScan,
<UDPPS Parameter> <value>
◊ <UDPPS Parameter> <value>
o TargetsToHit <integer>
The number of target addresses to scan. The default is 1.
o PortsToScan <integer>
The number of ports to scan on each target. The default is 65535.
The UDP header source port number. The default is 1024.
o StartingUDPDestPort <integer>
The first UDP header destination port number to scan. The default is 0.
• Unreachable Host Profile Parameters

An UnreachableHost attack sends ICMP host unreachable error messages to a
system, with the goal of tying it up and causing it to drop connections. This type of
attack can paralyze a system, even if the error messages are sent at very low rates.
Unreachable Host attack profile entries within the test configuration array should
WaDDOSAttack,<TestFileName>,UnreachableHost,
<UH Parameter> <value>
◊ <UH Parameter> <value>
default is 1000.
o UnreachableHostAddress <XX.XX.XX.XX>
The IP address of the unreachable host. The default is 10.0.0.1.
• XMas Tree Profile Parameters
An XMasTree attack generates a sequence of TCP packets with all bits in the TCP
header command field set. The packets are targeted at a specific network device
from a range of virtual source addresses. An XMasTree attack attempts to exploit a
bug that exists in some network devices that results in a system failure upon
receipt of the (malformed) XMasTree packet.
XMas Tree attack profile entries within the test configuration array should adhere
WaDDOSAttack,<TestFileName>,XMasTree,
<XMasTree Parameter> <value>
◊ <XMasTree Parameter> <value>
default is 1000.
WaCapRepTCP
Usage This feature allows you to replay captured protocols across a system or device under test.
Capture Replay is a send and expect protocol that works in conjunction with a server. You
must configure the flow of the session for both the client and the server consistently.
Information sent by the client is expected by the server and vice-versa. At the end of the
session, specify close on both sides, with the value specified as do or expect. (UDP forces
processing at the end of the session, so these commands can be omitted.)
You can either upload a capture (PCap) file or manually enter Capture Replay commands.
To manually specify Capture Replay commands in the test script, use the syntax shown in
Syntax1. To specify a capture (PCap) file to upload, use the syntax shown in Syntax2.
Note: If you choose to upload a capture file and specify a Pcap file in the PcapFile
parameter, all manual command entry parameters within the current profile will be
ignored and reported as unused within the current test.
Syntax1 WaCapRepTCP,<CapRepProfileName>,<ActionNumber>,<Parameter>
<value>
• <CapRepProfileName>
The name for this Capture Replay Profile on the target device. This name is used to
• <ActionNumber>
Integer value starting at 0 iterating with each individual action.
• Type <action_type>
The type of capture replay action required. See Table 3-1, “Capture Replay Action
Type List,” on page 107, for a list of acceptable action types.
• Value <value>
The value associated with the current action. Enter an argument for the action type
that you entered in the Type parameter. When entering send and expect action
types, you can specify strings that contain unprintable characters, such as, carriage
return, line feed, backspace, tab, and so on. You must use URL-style escaping to
encode these characters in the form of %xx, where xx is the character’s
hexadecimal code. For example, line feed is escaped as %0D, backspace is
escaped as %08, and so on.
• Min <integer>
Enter a minimum value if an applicable action type is chosen. See Table 3-1, for a
list of acceptable action types.
• Max <integer>
Enter a maximum value if an applicable action type is chosen. See Table 3-1, for a
list of acceptable action types.
Table 3-1. Capture Replay Action Type List
Action Type Minimum and Maximum Value
close No
expect No
expect_byte Yes
expect_counter16 No
expect_counter16n No
expect_counter32 No
expect_counter32n No
expect_counter No
expect_int32 Yes
expect_int32n Yes
expect_int8 Yes
expect_hist No
expect_int16 Yes
expect_int16n Yes
expect_int32 Yes
expect_int32n Yes
Table 3-1. Capture Replay Action Type List (continued)
Action Type Minimum and Maximum Value
expect_int8 Yes
force_send No
forms_db No
routing No (This parameter is valid only for
CapRepEth profiles)
send No
send_byte Yes
send_counter16 No
send_counter16n No
send_counter32 No
send_counter32n No
send_counter8 No
send_hist No
send_int16 Yes
send_int16n Yes
send_int32 Yes
send_int32n Yes
send_int8 Yes
timeout No
wait No
Syntax2 WaCapRepTCP,<CapRepProfileName>,<CapRep Parameter> <value>
• PcapFile <string>
Enter the name of the capture file (for example, http.pcap) to upload as a content
file. This file must be libpcap-compatible, such as that generated by Ethereal or
tcpdump or CAP files created using the Network Associates Sniffer 2.00x pro-
gram.
Note: When specifying a Pcap file in the PcapFile parameter, you must upload that
file with the test via the WaContent parameter.
• PreserveDelay true | false
Preserve inter-packet delay. Enter “true” if you want the client
to recreate a delay between packets if the delays are greater than 50
milliseconds in the capture file. (This parameter is used only when you have spec-
ified a Pcap file.) The default is false.
• AutoDiscover true | false
Enter “true” to have the client search the uploaded capture file and locate the TCP
session to use, identifying the start of the conversation. If you enable this option,
then the Destination host (DestHost) and Destination port (DestPort) parame-
ters are not required. (This parameter is used only when you have specified a Pcap
file.) The default is false.
• DestHost <X.X.X.X>
Enter the IP address of the actual server in the capture traffic. (This parameter is
used only when you have specified a Pcap file.)
• DestPort <integer>
Enter the port of the actual server in the capture traffic. (This parameter is used
only when you have specified a Pcap file.)
WaCapRepUDP
Usage Complete entries in the WaCapRepTCP parameter within the test configuration array to
set up a test to replay captured protocols across a system or device. Use UDP mode to
replay the traffic in datagram mode (UDP and generic protocol).
Syntax1 WaCapRepUDP,<CapRepProfileName>,<ActionNumber>,<Parameter>
<value>
• <ActionNumber>
The type of capture replay action required. See Table 3-1 on page 107, for a list of
acceptable action types.
• Value <value>
encode these characters in the form of %xx, where xx is the character’s hexadeci-
mal code. For example, line feed is escaped as %0D, backspace is escaped as %08,
and so on
• Min <integer>
Enter a minimum value if an applicable action type is chosen. See Table 3-1 on
page 107, for a list of acceptable action types.
• Max <integer>
Enter a maximum value if an applicable action type is chosen. See Table 3-1 on
Syntax2 WaCapRepUDP,<CapRepProfileName>,<CapRep Parameter> <value>
gram.
Note: When specifying a Pcap file in the PcapFile parameter, you must upload that
file with the test via the WaContent parameter.
Enter “true” to have the client search the uploaded capture file and locate the UDP
session to use, identifying the start of the conversation. If you enable this option,
then the Destination host (DestHost) and Destination port (DestPort) parame-
ters are not required. (This parameter is used only when you have specified a Pcap
file.) The default is false.
WaCapRepEth
Usage Complete entries in the WaCapRepEth parameter within the test configuration array to set
up a test to replay captured protocols across a system or device. Use Ethernet (Eth) mode
to replay the traffic down to the Ethernet layer (layer 2 of networking). Ethernet mode
replays traffic from all higher layers exactly as in the trace file. Since TCP and UDP are
layer 4, it is possible to replay a trace file that contains both TCP and UDP if the user
selects WaCapRepEth.
Syntax1 WaCapRepEth,<CapRepProfileName>,<ActionNumber>,<Parameter>
<value>
• <ActionNumber>
The type of capture replay action required. See Table 3-1 on page 107, for a list of
• Value <value>
encode these characters in the form of %xx, where xx is the character’s hexadeci-
mal code. For example, line feed is escaped as %0D, backspace is escaped as %08,
and so on
• Min <integer>
Enter a minimum value if an applicable action type is chosen. See Table 3-1 on
• Max <integer>
Enter a maximum value if an applicable action type is chosen. See Table 3-1 on
• First <XX:XX:XX:XX:XX:XX>
Enter the first gateway MAC address for the client. This parameter is applicable
only when the action type is “routing.”
• Last <XX:XX:XX:XX:XX:XX>
Enter the last gateway MAC address before the server. This parameter is applica-
ble only when the action type is “routing.”
Syntax2 WaCapRepEth,<CapRepProfileName>,<CapRep Parameter> <value>
gram.
Enter “true” to have the client search the uploaded capture file and locate the
Ethernet session to use, identifying the start of the conversation. If you enable this
option, then the Destination host (DestHost) and Destination port (DestPort)
parameters are not required. (This parameter is used only when you have specified
a Pcap file.) The default is false.
WaContent
Usage Use the WaContent parameters to upload content files to the client.
Syntax WaContent,<File Number> <File Location>
• <File Number>
Iterates with each new content file from 0 onwards. Each content file must have an
associated file number. For example, to upload two separate files, use the following
parameters:
WaContent,0 { C:\\Content\\Movie1.mov}
WaContent,1 { C:\\Content\\Movie2.mov}
• <File Location>
The full path and name of the content file. Enclose with curly braces {} if your path or
file name contains spaces.
WaFormDatabase
Usage Use the Client Form Database parameters to create a form data file for use with a Client
profile or PPP configuration to customize or modify the traffic specified by the Action
(URL) list. For example, you could simulate users logging in and submitting data to an
Internet site by creating a file of user names and passwords.
Typically, you use each row in a form data file to personalize an action list when a new
simulateD users is created. A file consists of key name/value pairs in a comma-separated
value (CSV) format, and simulates a user sending HTTP POSTs to an Internet site.
Note: If your form data file contains characters that an action list cannot accept, use the
URL Encode option to convert them to an acceptable form before sending the request.
Syntax WaFormDatabase,<FormDbProfileName>,<Parameter><value>
The input parameters and their values are described below:
• AutoInc on | off
To prompt each simulated user to use the next line in the form data file, enable this
auto increment option. The default is off.
If you enable AutoInc when creating a form data file, each simulated user is
assigned a database cursor that identifies the starting row of the database. All
database actions use the cursor to maintain a position in the database from which
they retrieve values. The first simulated user will get row 1, the second one will
get row 2, and so on.
If you use multiple CPUs, individual global variables are tied to each CPU. For
example, if you have two interfaces each with their own CPU (two interfaces and
two CPUs total), and both interfaces use the same forms data file, then two
simulated users get row 1, two get row 2, and so on. If you want every user to get
a unique row in the database, each client profile/interface should use its own
unique form data file.
• IgnoreFirstLine on | off
To skip the first line in the form data file, enable this option. The default is off.
This option allows you to use the first line to insert comments preceded by a "#"
symbol in files, or to ignore the column heads in a spreadsheet file.
• UrlEncode on | off
To encode URL values from the form data file before sending them in the request,
enable this option. This option converts characters that an action list cannot accept,
into an acceptable form. The default is off.
The use of some characters in a form data file can cause problems. If your form
data file contains characters that an action list cannot accept, use the UrlEncode
option to convert them to an acceptable form before sending the request.
The following list identifies a few characters that require use of the UrlEncode
option:
◊ Double quotes (" ") — Enter two quotes back to back.
◊ Comma (,) — Enter double quotes at the beginning and end of the field.
◊ Pound sign (#) — Use to insert comments. Nothing after the # is read.
◊ Percent sign (%) — Use for URL encoding.
◊ Left arrow (<) — Use for an action item (open)
◊ Right arrow (>) — Use for an action item (close)
• FdbFileLocation <file path>
Specify the location of the forms database file to be incorporated within the test,
for example, {c:\\FdbFiles\\DbTest0.txt} There is no default value.
WaHttpContent
Usage Use the HTTP Content parameters to create content files that you can send by using a
POST command in an action list during a test. The files can be ASCII or binary. You can
create a file by typing in the text or you can import a file.
Syntax WaHttpContent,<HttpContentProfileName>,<Parameter> <value>

• Type ascii | file
Specify the type of data you want to send.
• Body,Data <string>
If you specified “ascii” for the Type parameter, enter the text required for
your test.
Note: You cannot use reserved Tcl symbols within this entry (for example, you
cannot use the dollar sign ($). Also, if you attempt to specify exceptionally large
content within this tag, you may encounter issues relating to Tcl variable memory
usage. Refer to your Tcl documentation for any errors you encounter.
• ContentFileLocation <file path>

If you specified “file” for the Type parameter, specify the full path and name of
the required content file to be incorporated within the test, for example,
{c:\\HttpContentFiles\\content0.jpg
}
• EncodeFileContent yes | no
Enable or disable Base64 encoding of content files. Use this parameter only when
you specify “file” for the Type parameter. A test will not run if the content file is
not Base64 encoded, so only disable this parameter if the referenced file has
already been Base64 encoded. The default is yes.
WaCookieJarList
Usage Use the Cookie Jar List parameters to create or import a cookie jar file. To create a cookie
jar file, use the syntax shown in Syntax1. To import a cookie jar file, use the syntax shown
in Syntax2.
Syntax1 WaCookieJarList,<CookieJarProfileName>,CookieJar,<CookieJar
No.>,CookieJarList <value>
• <CookieJar No.>
An iterative index starting at 0, incrementing with every subsequent cookie jar
definition.
• CookieJarList <value>
Specify each cookie to include in the file. Use the input format of a standard Tcl
list; enclose items within curly braces and separate items with a space.
Syntax2 WaCookieJarList,<CookieJarProfileName>,CookieFileLocation
<cookie file path>
• CookieFileLocation <cookie file path>
The full path and name of the cookie jar file to import.
Note: If you import a cookie jar file, it is renamed with the name supplied in
the <CookieJarProfileName>. You cannot add additional cookie jars to the
current cookie jar profile name using the syntax shown in Syntax1.
WaHostFile
Usage Use the DNS host file parameters to create or import a DNS host profile. To create a DNS
host profile, use the syntax shown in Syntax1. To import and use an existing DNS host
profile, use the syntax shown in Syntax2.
Syntax1 WaHostFile,<HostFileProfileName>,Host,<Entry Index>,<HostFile

Parameter><value>
• <Entry Index>
An iterative index starting at 0, incrementing with every subsequent IP and Name
pairing.
• <HostFile Parameter> <value>
◊ Name <string>
Specify the host name which maps to the associated IP address you specified
in the IpAddress parameter.
◊ IpAddress <X.X.X.X>
Enter the IP address which maps to the host name you described in the Name
parameter.
Syntax2 WaHostFile,<HostFileProfileName>,<HostFileLocation><host file

path>
• <HostFileLocation> <host file path>
The full path and name of the DNS host file to import.
Note: If you import a DNS host profile, it is renamed with the name supplied in
the <HostFileProfileName>.
WaCertificate
Usage Use the WaCertificate parameters to upload SSL Authority and Revocation List certificate
files to the client. To upload one or more certificates to the client, use the following
syntax:
Syntax WaCertificate,<Certificate Type>,<File Number><File Location>

• <Certificate Type>
The type of certificate: Authority or Revocation.
• <File Number>
An iterative index starting at 0, incrementing with each new certificate file from 0
onward.
• <FileLocation> <host file path>
The full path and name of the certificate file to upload.
Note: Uploading a user certificate is handled through the use of the SSLConfig
attributes in the user profile. See SSLConfig on page 78 for more information.
Each Certificate file must have an associated <Certificate Type> and

<File Number>. The following example uploads two different Authority and
two different Revocation certificates:
WaCertificate,Authority,0 {C:\\Certificates\\authority0.pem}
WaCertificate,Authority,1 {C:\\Certificates\\authority1.pem}
WaCertificate,Revocation,0 {C:\\Certificates\\crl0.pem}
WaCertificate,Revocation,1 {C:\\Certificates\\crl1.pem}
Server Test Configuration Array Parameters

This section contains parameters to create and manipulate server Network, Interface,
Subnet, Server, and Transaction profiles.
The following parameters are described in this section:
• WrTestProfile
• WrNetworkProfile
• WrInterface
• WrSubnet
• WrStaticRouteTable
• WrServerProfile
• WrTransactionProfile
• WrContent
WrTestProfile
Usage Test profile entries for the server within the test configuration array.
Syntax WrTestProfile,<Parameter> <value>
Provide a description that indicates the purpose of the test.
• NetworkProfile {<NetworkProfile name>}
Specify the name of the Network Profile to use within this test. Network profile
parameters enable special routing (gateway and subnet), DNS (round robin), and
caching (proxy configuration) functionality, plus specify TCP parameters, such as
maximum segment size (MSS), attempts (retries), and packet contents (piggyback
GET request).
• Interface
Interface attributes within the Test Profile should adhere to the following syntax:
WrTestProfile,Interface,<InterfaceID>,
<Interface parameter> <value>
◊ <InterfaceID>
An integer value within the range 0 - 3, depending upon the total number of
available interfaces on the server.
◊ <Interface parameter> <value>
o Name {<interface profile name>}
Specify the name of the Interface Profile to associate with the interface
<InterfaceID>.
o PhysIf 0 | 1 | 2 | 3
Specify the physical port number associated with the current interface.
The default is empty.
o PhysIfDisplayString <string>
Specify a string to identify this physical interface (port) more easily in the
results (.csv) file. You cannot use commas within this parameter.
• SLBBinning on | off
Enables or disables this detailed reporting option.This option assists you in
determining if the load balancing policy of the SLB (server load balancer) is
working as expected. Enabling this option provides detailed granular information,
such as statistics per server on a test-wide basis. The default is off.
• DetailedHSC on | off
Enables or disables this detailed reporting option. This option enables you to view
the cumulative HTTP status codes received by the client during a test. The default
is off.
• SaveCookieJars on | off
Enables or disables cookie saving. When cookie saving is enabled, the client
records all cookies transmitted during a test, enabling you to create Cookie Jar
files automatically. Cookie Jar files must not exceed 64 megabytes. The default is
off.
• PktTrace on | off
Enables or disables the creation of a packet trace file. Enable this option if you
want the server to produce a PCAP (packet capture) file in addition to its normal
set of results files. The PCAP file (called trace.pcap) shows all packets sent and
received, and it can be read by many standard sniffer programs, such as Ethereal,
Netasyst (was Sniffer Pro), or ClearSight. The default is off.
• PktTraceBytes <integer>
The maximum size of the PCAP file in bytes. The maximum value that you can
enter is 9,999,360 bytes, which is also the default.
• UrlTrace on | off
Enables or disables the creation of an XML trace file. Enable if you want an XML
trace file for individual URLs, which contains errors, bindings of variables,
response latency, and so on. One trace file is generated per simulated user, called
httptracefile_X_trace.xml, where X is a number that represents the simulated user
associated with the file. You can view this file by using the URL Trace Tool. The
default is off.
• UrlTraceOnError on | off
Enable if you want only 4XX and 5XX HTTP error codes and content validation
failures reported. The default is on.
WrNetworkProfile
Usage The network profile describes the TCP characteristics of your network. Use the network
profile parameters to configure the server network characteristics that you want to
emulate.
Syntax WrNetworkProfile,<NetworkProfileName>,<Parameter> <value>
• <NetworkProfileName>
The name for this Network Profile on the server. This name is used to reference this
Write a short sentence describing the current test.
• IpReassemblyTimeout <integer>
Enter the maximum time the IP stack should wait for subsequent fragments after
receiving the first fragment of an IP datagram, in milliseconds. The default is
30000.
• TCPOptions TCPOptions attributes within the Network
Profile should adhere to the following syntax:
WrNetworkProfile,TCPOptions,<TCPOptions Parameter>
<value>
◊ <TCPOptions Parameter> <value>
o TCPMaxSegSize <integer>
Enter the maximum TCP segment size (in bytes) you want the TCP stack
to receive. Send segment size is determined by the communicating peer.
The specified value must be between 128 and 1460. The default is 1460.
o TCPReceiveWindowSize <integer>
Enter the bytes that you want to use. The receive window informs the peer
how many bytes of data the stack is currently able to receive. The sup-
plied value is used in all segments sent by the stack. The default is 32768.
o TCPDelayedAcks on | off
Enable or disable the delaying of ACKs. This option causes the TCP stack
to implement the Delayed ACK strategy, which attempts to minimize the
transmission of zero-payload ACK packets. Acknowledgements will be
deferred in the hopes of piggybacking them on top of valid data packets.
If successfully deferred, these acknowledgements are free, in the sense
that they consume no additional bandwidth. The default is on.
o TCPDelayedAckTimeout <integer>
Enter the Delayed ACK Timeout in milliseconds. If you enable
TCPDelayedAcks, use this timeout value to specify the maximum time
the TCP stack waits to defer ACK transmission. If this timer expires, the
stack transmits a zero-payload acknowledgement.The default is 200.
o TCPDelayedAckBytes <integer>
Enter the number of bytes of data that you want the TCP stack to send as
an ACK packet. The default is 2920. Only use this parameter if you
enabled TCPDelayedAcks.
o TCPCongestionControl on | off
Enable to invoke the TCP stack's congestion control mechanism. If
enabled, the TCP stack implements Slow Start and Congestion
Avoidance, according to RFC 2581. The default is on.
o TCPTimeout <integer>
Enter a TCP Timeout value in milliseconds which will override the inter-
nally calculated TCP stack timeout value. This value is used if
<TCPTimeoutOverride> is ‘on’. The default is 2000.
o TCPTimeoutOverride on off
Enable or disable TCP Timeout override. If enabled the manual timeout
specified by TCPTimeout is used. The default is off.
o TCPRetries <integer>
Enter the number of times a timed-out packet is retransmitted before
aborting further retransmission. If the client does not receive a response
after the configured number of retries have been attempted, the error is
logged in the results.CSV file as a TCP timeout when a SYN is sent and
no SYN/ACK from the server is received. The default is 2.
o TCPInactivityTimeout <integer>
Enter the amount of time (in milliseconds) that passes before the client
resets (the stack sends an RST segment) and abandons inactive
connections. A value of 0 disables the timer. You must disable this timer
for each streaming test. The default is 0.
WrInterface
Usage The interface profile describes each interface port on the server. For each physical port on
your server, assign an interface profile to that port. If you do not want to accept any traffic
from a port, do not specify any TCP parameters.
Syntax WrInterface,<InterfaceProfileName>,<Interface Parameter>

<value>
• <InterfaceProfileName>
The name for this Interface Profile on the server. This name is used to reference this
• <Interface Parameter> <value>
Write a short sentence describing the interface profile.
• GratuitousARP on | off
This option broadcasts an ARP (Address Resolution Protocol) request with the
port’s IP address at the beginning of each test. This ensures that a device con-
nected to the port has the correct ARP cache data. The default is on.
• Subnets {<subnet profile name1> <subnet profile name2>}
Specify the subnet profile name(s) of the current subnet(s). The input format is
similar to a standard Tcl list; enclose items within curly braces and separate items
with a space.
• Router
Interface profile router attributes within the test configuration array should adhere
WrInterface,<InterfaceProfileName>,Router,
<Router Parameter> <value>
o IpAddress X.X.X.X
Enter the outbound address and local network of the router emulated by
the interface. Use CIDR (dotted decimal) notation, and the number of bits
in the network part of the address in the NetmaskBits parameter.
Enter the virtual router’s netmask.
WrStaticRouteTable to create the static routing table.
• RouterSet <RouterSet parameter> <value>
Use the RouterSet option to emulate a router for this subnet.
Interface profile RouterSet attributes within the test configuration array should
WrInterface,<InterfaceProfileName>,RouterSet,<RouterCon-
figNumber>,<RouterSet Parameter> <value>
◊ <RouterConfigNumber>
◊ <RouterSet parameter><value>
o IpAddress X.X.X.X
Specify a virtual router IP address.
Specify the virtual router’s netmask.
WrStaticRouteTable to populate the static routing table.
o InsertVlanTag on | off
o VlanId <integer>
Specify a VLAN ID to include when InsertVlanTag is enabled. The
default is 1.
o Enabled on | off
Interface profile RouterSet MacMasquerade attributes within the test configura-

WrInterface,<InterfaceProfileName>,RouterSet,<RouterCon-
figNum>,MacMasquerade,<MAC Parameter><value>
◊ <RouterConfigNum>
Iterates with each new router definition from 0 onwards..
◊ <MAC parameter> <value>
o Enabled on | off
o Mac0 <00-FF>
Specify the first MAC address byte. The default is 00.
o Mac1 <00-FF>
Specify the second MAC address byte. The default is 00.
WrSubnet
Usage Configure subnet configuration profiles. You can define static routing, IP fragmentation,
realism, and PPP/PPPoE for one or more selected configurations.
Syntax WrSubnet,<SubnetProfileName>,<Parameter> <value>
• <SubnetProfileName>
The name of the subnet profile to configure.

Write a short sentence describing the subnet profile.
• IpVersion 4 | 6
Enter either 4 for IPv4 or 6 for IPv6 based on the IP version of your subnets.
Enter the network address of your subnet, using CIDR notation (dotted decimal).
• NetmaskBits <integer>
Enter the number of bits in the network part of the address. For example, 24 repre-
sents 255.255.255.0, while16 represents 255.255.0.0. The default is 24.
• SendSide
Subnet profile SendSide attributes within the test configuration array should
WrSubnet,<SubnetProfileName>,SendSide,
<SendSide Parameter> <value>
◊ <SendSide Parameter> <value>
o ConnectionNoise <integer>
Enter the percentage packet loss multiplied by 1000 on the link. For
example 50% packet loss equates to a ConnectionNoise value of 50000.
The default is 0.
o ConnectionSpeed <integer>
Enter the bits per second (bps) or link speed that a simulated user will use
to connect to a network. The default is 0.
o NPacketsToDrop <integer>
Enter the number of packets to drop. When a packet must be dropped,
the number of successive packets dropped is decreased by one. Any
succeeding packets for that same subnet will be dropped, until the packets
dropped value in the subnet becomes zero. Once this value is zero, the
cycle repeats. The default is 0.
o EndToEndDelay <integer>
Enter a fixed link propagation delay (in milliseconds) that emulates the
distance of the subnets involved. To this delay, you can also add a Delay
Variation (see the next description) that emulates the queuing and
processing delay at intermediate hops in the internet/network. The sum of
these two delays is the total delay that used per packet. You can configure
these delays on a per subnet basis for outgoing and incoming traffic
separately (that is, Receive Side and Send Side of the interface). The
default is 0.
o DelayVarianceMethod 0 | 1 | 2
concentration of members around the middle and less on the tails of the
curve. The default is 0.
o DelayVarianceVal1 <integer>
If DelayVariationMethod is specified as 1 or 2, then use this
parameter to specify the start of the delay variances. The default is 0.
parameter to specify the end of the delay variances. The default is 0.
• RecvSide
Subnet profile RecvSide attributes within the test configuration array should
WrSubnet,<SubnetProfileName>,RecvSide,
<RecvSide Parameter> <value>
◊ <RecvSide Parameter> <value>
o ConnectionNoise <integer>
Enter the percentage packet loss multiplied by 1000 on the link. For
example 50% packet loss equates to a ConnectionNoise value of 50000.
The default is 0.
o ConnectionSpeed <integer>
Enter the bits per second (bps) or link speed that a simulated user will use
to connect to a network. The default is 0.
o NPacketsToDrop <integer>
Enter the number of packets to drop. When a packet must be dropped, the
number of successive packets dropped is decreased by one. Any
succeeding packets for that same subnet will be dropped, until the packets
dropped value in the subnet becomes zero. Once this value is zero, the
cycle repeats. The default is 0.
o EndToEndDelay <integer>
Enter a fixed link propagation delay (in milliseconds) that emulates the
distance of the subnets involved. To this delay, you can also add a Delay
Variation (see the next description) that emulates the queuing and
processing delay at intermediate hops in the internet/network. The sum of
these two delays is the total delay that used per packet. You can configure
these delays on a per subnet basis for outgoing and incoming traffic
separately (that is, Receive Side and Send Side of the interface). The
default is 0.
o DelayVarianceMethod 0 | 1 | 2
concentration of members around the middle and less on the tails of the
curve. The default is 0.
parameter to specify the start of the delay variances. The default is 0.
parameter to specify the end of the delay variances. The default is 0.
• IpQosValue <integer>
(Send side only) The type of service value is any number between 0 and 255
that is inserted in the IP header of all outgoing segments from the subnet. The
default is 0.
• InsertVlanTag on | off
• VlanId <integer>
Specify a VLAN ID to include in every packet transmitted from this subnet. This
ID will be used when InsertVlanTag is enabled. The default is 0.
• VlanPriority <integer>
Specify the user priority for the VLAN. The valid range is 0 to 7. The default is 0.
• VlanCFI <integer>
Specify the one-bit canonical format indicator (CFI) for the VLAN. The default is
0.
• IpFrag
Subnet profile IpFrag attributes within the test configuration array should adhere
WrSubnet,<SubnetProfileName>,IpFrag,<IpFrag Parameter>
<value>
◊ <IpFrag Parameter> <value>
o Enabled on | off
Enable or disable IP Fragmentation. Enable to fragment all datagrams
transmitted from this subnet. The default is off.
o FragmentSize <integer>
The number of bytes contained in each fragment. Any number is
accepted, however, fragment size must be a multiple of eight, so that the
IP stack rounds up to the nearest multiple of eight. The default is 128.
o PacketsPerMillion <integer>
Enter the fragmentation index which equates to a fragmentation
percentage multiplied by 10000. For example 5% packet fragmentation
equates to a PacketsPerMillion value of 50000. The default is1000000
(one million).
o SendInReverseOrder on | off
Enable or disable transmitting fragments in reverse order. This option
allows testing of worst-case reassembly scenarios. The default is off.
o SendFirstOnly on | off
Enable or disable sending the first fragment. Enable to transmit only the
first fragment of each datagram. All other fragments are discarded. If you
enabled SendInReverseOrder, only the fragment that would have been
sent last is sent. This option allows you to test reassembly timeout mecha-
nisms. The default is off.
o OverlapFragments on | off
Enable or disable sending overlapping fragments. Enable to cause the IP
stack to create and send random, but legitimate, IP fragments whose data
offset and length are randomly selected so that the receiving end sees
overlapping data in the fragments it receives. The overlapping fragment
will not have enough data for the receiving end to complete the reassem-
bly, and overlapping fragments are sent only if the original IP datagram is
at least 24 bytes long. The best effort is made to insert the overlapping
fragments in between regular fragments, but they are not guaranteed to
always be inserted (because of their random nature), and they are never
inserted after the last regular fragment is sent. This option is useful for
testing the reassembly mechanisms at the other end. The default is off.
• MacMasquerade
Subnet profile MacMasquerade attributes within the test configuration array
WrSubnet,<SubnetProfileName>,MacMasquerade,
<MAC Parameter><value>
◊ <MAC Parameter> <value>
o Enabled on | off
o Mac0 <00-FF>
Enter the first MAC address byte. The default is 00.
o Mac1 <00-FF>
Enter the second MAC address byte. The default is 00.
• UsePPPoE on | off
Enable or disable additional PPP parameters required for the Point-to-Point over
Ethernet (PPPoE) Protocol. Enable to use a PPPoE configuration, and then specify
the PPPoE configuration that you want to apply to the subnet. The default is off.
• UsePPP on | off
Enable or disable Point-to-Point Protocol (PPP) parameters. The default is off.
• DefaultGatewayEnabled on | off
Enable or disable the use of a default gateway. The default is off. When you enable
the default gateway, the client creates and enables the static routing table that
includes the specified gateway address. Therefore, if you enable this parameter,
you must also: configure the appropriate static routing table (see WrStati-
cRouteTable), enable it via WrSubnet,<SubnetProfile-
Name>,Router,Enabled, reference the appropriate routing table via
WrSubnet,<SubnetProfile Name>,Router,StaticRouteTa-
ble,<StaticRouteFilename>, and configure this table with the default gate-
way address (see GatewayAddress <X.X.X.X>).
• ServerProfile
Subnet profile ServerProfile attributes within the test configuration array should
WrSubnet,<SubnetProfileName>,ServerProfile,
<ServerProfileNumber>, <Server Parameter><value>
◊ <ServerProfileNumber>
Iterates with each new server profile definition from 0 onwards.
◊ <Server Parameter><value>
Specify the parameter as one of the following values:
o Name <Server Profile Name>
Specify the Server Profile name.
o IpVersion 4 | 6
Specify the IP Version as either 4 or 6.
o IpAddressRange <X.X.X.X | X.X.X.X-X.X.X.X>
Enter the IP address or range from which you want to generate traffic.
XX:XX:XX:XX:XX:XX>
• Router
Router profile attributes within the test configuration array should adhere to the
following syntax:
WrSubnet,<SubnetProfileName>,Router,<Router Parameter>
<value>
o StaticRouteTable <StaticRouteFileName>
Specify the name of the XML file containing the static routing table. To
create this table, use the WrStaticRouteTable parameter.
• MacAddressRanges
MacAddressRanges profile attributes within the test configuration array should
WrSubnet,<SubnetProfileName>,MacAddressRanges,<Ranges
Parameter> <value>,
◊ <Ranges Parameter> <value>
XX:XX:XX:XX:XX:XX>
• IPSec Parameters
Use the IPSec parameters to configure the server’s VPN settings. Subnet IPSec
profile attributes within the test configuration array should adhere to the following
syntax:
WrSubnet,<SubnetProfileName>,IPSec,<IPSec Parameter>
<value>
◊ <IPSec Parameter> <value>
o Enabled on | off
Enable or disable IP security for this subnet. The default is off.
o IkePhase1Mode Aggressive | Main

Specify the mode to use for Phase 1 exchange. This mode determines the
messages that are exchanged between the initiator and responder to nego-
tiate the Phase 1 Security Association (SA).
∇ Aggressive mode is used to negotiate IKE Phase 1 SAs when the pro-
tection of identity information is NOT necessary. This allows the
messages involved in the key exchange and authentication to be
transmitted together and reduces the number of round trips required
for the negotiation. The drawback to Aggressive mode is that the
identity information is not protected. The default is Aggressive.
∇ Main mode is used to negotiate IKE Phase 1 SAs when the protection
of identity information IS necessary. There are six messages
exchanged during the first phase of the IKE negotiation in Main
mode. The messages exchanged vary depending on the method used
to authenticate the peers.
o AuthMeth Preshared | RSA | XAuth
Enter the authentication method for phase 1.
∇ Preshared (site-to-site only) - If you enter this, you must also include
the PresharedKey parameter to specify the key string for this type of
authentication.
∇ RSA (site-to-site only)
∇ XAuth (Extended Authentication, remote-access tunnels only) - If
you enter XAuth, you must also include the Type parameter to indi-
cate the type of XAuth for phase 1 (Generic, Cisco, or Nortel).
o IsakmpIdentification <string>
Enter the Internet Security Association and Key Management Protocol
(ISAKMP) identification payload. ISAKMP defines procedures and
packet formats to establish, negotiate, modify and delete security associa-
tions.
o PresharedKey <string>
Enter the key string to use when doing Preshared Key authentication. Pre-
shared means that the parties agree on a shared, secret key that is used for
authentication in an IPSec policy.
o CACertFileLocation <file path>
Enter the location of the certifying authority's certificate file to be incor-
porated within the test, for example, {c:\\certs\\cacert.pem}.
The X.509 format certificate file name of the tunnel endpoint. (Enabled
only when the Authentication method specifed for AuthMeth is RSA.)
Note: Certificate files are generally large. The MTU (maximum

transmission unit) containing the IKE message can be larger then 1500
bytes, in which case the packet will be silently dropped by the NIC.
Therefore, you should turn on fragmentation (e.g., with a size of 512 or
1000 bytes) for both the client and server subnets.
o CertFileLocation <file path>

Enter the location of the certificate file to incorporate within the test, for
example, {c:\\certs\\cert.pem}.
o PrivKeyFileLocation <file path>
Enter the location of Private Key file to be incorporated within the test,
for example, {c:\\certs\\privkey.pem}.
o EncAlg DES | 3DES | AES-128 | AES-192 | AES-256
Specify the encryption algorithm to used for Phase 1 to transform the pay-
load data in the packets from an intelligible form (plaintext) into an unin-
telligible form (ciphertext), and back:
∇ DES: The Data Encryption Standard, defined by the U.S. govern-
ment. DES is a symmetric 64-bit block cipher that uses a 56-bit key.
∇ 3DES: A variant of DES, and is the most accepted method. 3DES is a
combined set of two DES keys totalling 112 bits. Due to its larger
size, 3DES is considered much more secure that DES.
∇ AES-128: AES (Advanced Encryption Standard) with a 128-bit key.
o HashAlg MD5 | SHA-1
Specify the hash authentication method used for Phase 1 to verify that the
packets being received were sent by the stated source:
∇ MD5 - A message-digest algorithm that derives a secure, irreversible,
than SHA-1.
∇ SHA-1 - The Secure Hash Algorithm version one, part of the U.S.
secure.
o DHGroup MODP-768 | MODP-1024 | MODP-1536
Specify the Diffie-Hellman group for Phase 1:
The size of the group determines the level of security of the Diffie-
Hellman key exchange. (The higher the group number, the greater the
security.) The groups use traditional exponentiation over a prime modulus
data.
o Ph1EncryptPkt3 on | off
Enable or disable encryption of the third packet of Phase 1 aggressive
mode exchange. The default is off.
o IkeLifetimeSecs <integer>
Enter the lifetime in seconds of the Phase 1 IKE connection. The default
is 28,800 seconds.
o IkeReconnThresh <integer>
Enter the time limit in seconds after the IKE Lifetime expires when a
Phase 1 connection is re-keyed. The default is 20 seconds.
o Ph2DHGroup None | MODP-768 | MODP-1024 | MODP-1536
Specify the Diffie-Hellman group for Phase 2, used to generate the sym-
metric key for PFS:
∇ None (PFS is not used)
The size of the group determines the level of security of the Diffie-
Hellman key exchange. (The higher the group number, the greater the
security.) The groups use traditional exponentiation over a prime modulus
data.
o EspTransformId ESP-DES | ESP-3DES | ESP-AES-128 |
ESP-AES-192 | ESP-AES-256
The encryption method used for Phase 2 to transform the payload data in
the packets from an intelligible form (plain text) into an unintelligible
form (cipher text), and back.
Specify the encryption algorithm to use for the ESP tunneled packets:
∇ ESP-DES: The Data Encryption Standard, defined by the U.S. gov-
ernment. DES is a symmetric 64-bit block cipher that uses a 56-bit
key.
∇ ESP-3DES: A variant of DES, and is the most accepted method.
3DES is a combined set of two DES keys totalling 112 bits. Due to its
larger size, 3DES is considered much more secure that DES.
∇ ESP-AES-128: AES (Advanced Encryption Standard) with a 128-bit
key.

o Ph2HashAlg MD5 | SHA-1
The hash authentication method used for Phase 2 to verify that the packets
being received were sent by the stated source. Specify the hash algorithm
to be used for the tunneled packets:
∇ MD5: A message-digest algorithm that derives a secure, irreversible,
than SHA-1.
∇ SHA-1: The Secure Hash Algorithm version one, part of the U.S.
secure.
o SaLdSecLife <integer>
Enter the Security Association (SA) lifetime in seconds for the estab-
lished tunnel. The default is 28,800 seconds.
o RekeyThreshSecs <integer>
Enter the time limit in seconds before the SaLD Lifetime expires, when a
re-key for Phase 2 is started. The default is 30 seconds.
o IkeTimeout <integer>
Enter the time limit after which any Phase 1 or 2 messages will be trans-
mitted, in seconds.
o IkeRetries <integer>
Enter the maximum number of re-transmissions for any of the Phase 1
and Phase 2 messages. The default is 5.
o Address <X.X.X.X>
Enter the subnet from which IP addresses are generated when the authen-
tication mode is XAuth (that is, you specified XAuth for the AuthMeth
parameter).
o Netmask <X.X.X.X>
Enter the subnet mask for the address specified in the Address parame-
ter (above).
o DNS <X.X.X.X>
Enter the primary DNS server’s IP address for the subnet specified in the
Address parameter (above).
o DNS2 <X.X.X.X>
Enter the secondary DNS server’s IP address for the subnet specified in
the Address parameter (above).
o Ph2NumTunnels 1-per-Subnet | 1-per-Host
Specify the number of tunnels to open: 1-per-Subnet (site-to-site tunnels)
or 1-per-Host (remote access emulation). The default is 1-per-Subnet.
o Ph2CommitBit on | off
Enable or disable the Phase 2 Commit bit. This bit ensures that the IPSec
tunnel has successfully completed the Phase 2 Quick mode exchange. The
default is off.
• Tunneling
Subnet profile Tunneling attributes within the test configuration array should
WrSubnet,<SubnetProfileName>,Tunneling,<Tunneling Parame-
ter> <value>
◊ <Tunneling Parameter> <value>
o Gateway on | off
Enable or disable tunneling. The default is on.
o Persistent on | off
Specify whether the tunnel is persistent. The default is off (not persistent).
o GwIpVer 4 | 6
Specify the IP version of the gateways in a site-to-site tunnel. The default
is 4.
o LocalGwMacAddr <XX:XX:XX:XX:XX:XX>
Enter the MAC Address of the local gateway. This is only used in a 'site-
to-site' scenario.
o LocalGwIpAddr <X.X.X.X>
Enter the IP Address of the local gateway. This is only used for IPv4
addresses. (IPv6 addresses are derived from the MAC Address.)
o RemoteGwIpAddr <X.X.X.X> | <IPv6 IP>
Enter the IP Address of the remote gateway, in either IPv4 or IPv6 format.
For remote-access tunnels, use the LocalGwIPVer parameter instead.
• XAuth
IKE Extended Authentication (XAuth) is a protocol for authenticating user names
and passwords before the tunnel is opened.
Subnet profile XAuth attributes within the test configuration array should adhere
WrSubnet,<SubnetProfileName>,XAuth,<XAuth Parameter>
<value>
Note: You must provide the XAuth attributes only when the IPSec <AuthMeth>
attribute is set to XAuth.
◊ <XAuth Parameter> <value>

o UsernameWildcardBase <string>
Specify the string base from which the user names are generated. Valid
only at the client side (that is, Avalanche). The default string is User####.
o PasswordWildcardBase <string>
Specify the string base from which passwords are generated. Valid only at
the client side (that is, Avalanche). The default string is Password####.
o Type Generic | Cisco-EasyVPN | Nortel-Contivity
Specify the type of 'XAuth' to be performed:
∇ Generic: The default value.
∇ Cisco-EasyVPN
∇ Nortel-Contivity:
o Ip6Prefix <Ipv6 address>
Enter an IPv6 prefix address using colon hexadecimal notation for the
XAuth network specified in Ip6MacRange. For example:
Prefix Address = 3FFE::0
Interface ID = 200:FF:FE00:101-200:FF:FE00:1FF
Prefix Length = 64 bits
The first address in the range would be 3FFE::200:FF:FE00:101.
o Ip6Mask <integer>
Enter an IPv6 prefix length in bits, from 16 to 128 for the XAuth network
specified in Ip6MacRange.
o Ip6MacRange <Ipv6 Mac range>
Specify the MAC address or range used for generating IPv6 addresses
when the authentication mode is XAuth.
o Ip6DNS1 <Ipv6 address>
Specify the primary DNS server's IP address for the XAuth network spec-
ified in Ip6MacRange.
o Ip6DNS2 <Ipv6 address>
Specify the secondary DNS server's IP address for the XAuth network
specified in Ip6MacRange.
o RemoteNetworkVersion 4 | 6
Specify the IP version of the remote network. Possible values are 4 for
Ipv4 and 6 for Ipv6.
• ForcedPathMTU
Subnet profile Forced Path MTU (maximum transmission unit) attributes within
the test configuration array should adhere to the following syntax:
WrSubnet,<SubnetProfileName>,ForcedPathMTU,<MTU Parame-
ter> <value>
◊ <MTU Parameter> <value>
o Enabled on | off
Enable or disable this functionality. The default value is on.
o Size <integer>
Specify the size of the maximum transmission unit (MTU). The default is
1500 bytes.
• IPV6
Use the IPV6 subnet profile when configuring an IPv6 subnet.
Subnet profile IPv6 attributes within the test configuration array should adhere to
WrSubnet,<SubnetProfileName>,IPV6,<IPV6 Parameter><value>
◊ <IPV6 Parameter> <value>
o AssignPrefix on | off
Enable or disable the addition of a prefix (mask) for the Ipv6 subnet. The
default value is off. An IPv6 prefix indicates the fixed part of the address.
(As in IPv4 CIDR notation, this defines the network portion of the
address.) Specify an IPv6 address range using an IPv6 prefix address
(PrefixAddress)and prefix length (PrefixLength).
o PrefixAddress <IPv6 prefix>
Specify the IPv6 prefix address to use if you enabled the AssignPrefix
parameter. The default value is 3FFE::0. Use this parameter with <Pre-
fixLength> to specify the network part of an IPv6 subnet.
o PrefixLength <integer>
Specify the IPv6 prefix length in bits, from 16 to 128. The default value is
64. Use this parameter with <PrefixAddress> to specify the network
part of an IPv6 subnet.
o AddressRanges
Subnet profile AddressRanges attributes within the test configuration
WrSubnet,<SubnetProfileName>,IPV6,Address-
Ranges,<Ranges Parameter><value>
∇ Specify two IPv6 addresses separated by a hypen (-) to indicate the

IPv6 address range. The default is 3FFE::0200:FF:FE00:1-
3FFE::0200:FF:FE00:FF.
o UseMacAddress on | off
Enable or disable the use of the MAC address range specified in the
<MacAddressRanges> parameter to generate the associated IPv6 address
range. The default value is off. If you do not want to use a MAC address
range, then you must specify the prefix address, prefix length, and address
range parameters for the IPv6 subnet.
WrStaticRouteTable
Usage Use the static routing table profile parameters to create a static routing XML configuration
file for a routed network.
Syntax WrStaticRouteTable,<StaticRouteFilename>,Route,
<RouteNumber><Parameter> <value>
• <StaticRouteFileName>
The name of the name of the static routing XML configuration file to create.
• <RouteNumber>
Iterates with each new routing table entry from 0 onwards.
Enter the address of the network for which this routing table entry applies.
• NetMaskBits <integer>
Enter the number of bits in the specified network that comprise the network part of
the address.
• GatewayAddress <X.X.X.X>
Enter the address of the gateway to which you send packets destined for the speci-
fied network.
WrServerProfile
Usage Use the Server Profile parameters to configure information for the server protocol that you
want to test.
Syntax WrServerProfile,<ServerProfileName>,<Parameter> <value>
• <ServerProfileName>
The name of the server you are configuring.
Provide a description of the current test.
• Port <integer>
Specifies the server port number
• ApplicationProtocol HTTP | HTTPS | FTP | Streaming | MMS |
POP3 | IMAP4 | SMTP | Telnet | DNS | CapRepTCP | CapRepUDP
| Mcast | SIPUDP | SIPTCP | MM4
Specify the server protocol that you want to emulate.
• FTP
For an FTP application protocol, the user is only required to specify the Appli-
cationProtocol parameter and the <Port> parameter (21).
• HTTP
HTTP server profile entries within the test configuration array should adhere to the
following syntax:
WrServerProfile,<ServerProfileName>,HTTP,<HTTP Parameter>
<value>
◊ <HTTP Parameter> <value>
o ServerType <string>
Specify the server type, for example, EE or IIS5. The default is IIS5.
o HttpVersion 1 | 2
Enter 1 to use HTTP 1.0, or 2 to use HTTP 1.1. The default is 2.
o KeepAlive on | off
Enable or disable this option if you selected HTTP 1.0. If enabled, it
activates the Keep-Alive function, which keeps the connection open after
the initial request is accepted, so that subsequent responses can be sent
over the same TCP connection. This saves the overhead associated with
establishing and tearing down TCP connections. The default is on.
o MaxRequests <integer>
If you selected HTTP 1.1, enter the maximum number of responses sent
over the same TCP connection.The default is 64.
o DefTxnProfile <profileName>
Specify the transaction profile that you want to assign to this server. The
default is Default.
o UpdatePct <integer>
Define the percentage of the time a server cookie will be updated. For
example, defining 45% results in 45% chance that a server cookie will be
updated. Because this parameter is expressed as a percentage, only values
from 0 to 100 are permitted. The default is 0.
Note: The sum of Update Cookie Frequency and Delete Cookie

Frequency must not exceed 100 percent. However, The total percentages
entered for cookie management must equal 100% before continuing.
o DeletePct <integer>
Define the percentage of the time a server cookie will be deleted. For
example, defining 45% results in 45% chance that a server cookie will be
deleted. Because this parameter is expressed as a percentage, only values
from 0 to 100 are permitted. The default is 0.
o NewPct <integer>
Define the percentage of the time cookies are created on a response per
response basis. For example, defining 45% results in 45% of all server
responses creating a cookie in the response (until the maximum number
of allowable cookies is reached). Because this parameter is expressed as a
percentage, only values from 0 to 100 are permitted. The default is 0.
o ActivateCookies on | off
Enable or disable cookies. The default is off.
o NumCookies <integer>
Enter the maximum number of allowable cookies that the server will cre-
ate. The default is 100.
o CookieExpiresProgram 1 | 2 | 3
Specify the method of cookie expiration: 1 for None, 2 for Fixed, and 3
for Normal. The default is 1.
∇ None: Turns off the Expires feature. If your test does not involve the
use of cache devices, it is suggested that you select this option.
∇ Fixed Distribution: Allows you to enter a fixed timestamp that will be
sent in the Expires header every time the server serves the transac-
tion.
∇ Normal Distribution: Allows you to select a normal distribution as

the means to generate an offset (time difference) from the Last Modi-
fied time. A normal distribution, frequently referred to as a Bell
Curve, has a concentration of members around the middle and less on
the tails of the curve. Every normal distribution has a mean and a
standard deviation that shows how much the values deviate from the
mean. The emulated server uses the values specified here to create a
normal distribution, which in turn is used to select an offset.
o CookieExpiresDateTime <formatted string>
Specify the date and time that a cookie will expire. The format of this
entry must be as follows: <day>, <date> <time> <zone>
For example: Thu, 06 May 2004 01:02:03 GMT. The default is an empty
string.
o CookieExpiresPercent <integer>
Define the percentage of the time a server cookie will expire. The default
is 0.
o CookieExpiresNormalMeanSeconds <integer>
Enter the number of seconds used as the mean number for the normal dis-
tribution This parameter is used when <CookieExpiresProgram> is set to
o CookieExpiresNormalSDMinutes <integer>
Enter the number of seconds that the data in the distribution deviates from
the mean. This parameter is used when <CookieExpiresProgram> is set to
o LightWeightFull on | off
Use the pre-built HTTP response to improve performance, provided you
configure the profile to meet the following conditions:
∇ Cookie management is not enabled for the server.
∇ The HTTP request does not specify an alternate transaction profile.
∇ The default transaction profile for the server does not specify
dynamic response elements, which implies that headers have a fixed
format and that the size and content of the response body are fixed.
If the above conditions are not met, the correct response will still be sent,
but in a non-streamlined mode. Therefore, enabling this option will
improve performance, whenever possible, providing the correct response.
The default is off.
o LightWeightPartial on | off
Select to receive a higher increase in performance than with the Improved
Performance with Full Compatibility option. (See the previous defini-
tion.) However, the functions supported are more limited:
∇ Cookies are not supported.
∇ The pre-built HTTP response is always returned, regardless of the

HTTP request elements. Only the following elements are obtained
from the HTTP request: Request type (method), HTTP version, and
Connection header.
All other request elements are ignored, and therefore, are not validated.
The default is off.
• HTTPS
HTTPS server profile entries within the test configuration array consist of a
combination of HTTP and SSL parameters. HTTP parameters are discussed in the
previous bullet.
SSL parameters should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,SSLConfig,
<SSLConfig Parameter> <value>
Note: To instigate an HTTPS profile within a test, the <ApplicationProto-

col> parameter must be set to HTTPS. Also remember to set the <Port> param-
eter to 443 if configuring using default values.
◊ <SSLConfig Parameter> <value>

o Versions {SSLv2 SSLv3 TLSv1}
Specify the SSL version(s) to use. The input format is similar to a
standard Tcl list; enclose items within curly braces and separate items
with a space. The default is SSLv2.
o SslAcceleration on | off
Enable or disable hardware SSL acceleration. The default is on.
o VerifyClient 0 |1 | 2
Specify the required level of client authentication from the following
options:
0 - No certificate checking. Disables certificate verification.
1 - Valid certificate optional. If a certificate is specified, then it must be
valid. It is acceptable not to specify a certificate.
2 - Valid certificate mandatory. The certificate specified must be valid.
That is, it must be signed by a valid CA, and not have expired or been
revoked, in order for the transaction to continue.
The default is 0.
o SendCloseNotify on | off
Enable or disable close notification. Enable to notify the recipient that the
sender will not send any more messages on this connection. The default
is off.
o AuthorityCertificate <authority certificate file

ServerCertificate <server certificate file path>
Specify the location of the server certificate file to be incorporated within
the test, for example, {c:\\Certs\\server.pem}.
• HTTPS Server SSLConfig CipherSuite Profile Parameters
HTTPS Server SSLConfig profile CipherSuite attributes within the test
configuration array should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,SSLConfig,
CipherSuite,<Cipher Parameter> <value>
◊ <Cipher Parameter> <value>
o Cipher {<Cipher1> | <Cipher2> | <Cipher3>}
Specify a list of ciphers to use. The input format is similar to a standard
Tcl list; enclose items within curly braces and separate items with a space.
• SMTP
SMTP server profile entries within the test configuration array should adhere to
WrServerProfile,<ServerProfileName>,SMTP,
<SMTP Parameter> <value>
Note: To instigate this profile within a test, the <ApplicationProtocol>

parameter must be set to SMTP. Also remember to set the <Port> parameter to
25 if configuring using default values.
◊ <SMTP Parameter> <value>

o PoTMailBoxUnavailable <integer>
Enter the percentage of time between 0 - 100 that the mailbox is
unavailable. The server will reply with a 450 status code. The default is 1.
o PoTOutofStorage <integer>
Enter the percentage of time between 0 - 100 that the mailbox is out of
storage. The server will reply with a 451 status code. The default is 2.
o PoTExceedingStorage <integer>
Enter the percentage of time mailbox is out of storage, between 0 - 100.
The server will reply with a 552 status code. The default is 3.
o ESMTPSupported on | off
Enable or disable responses to ESMTP messages. Enable this option to
generate a response for the following commands: RSET, EHLO, SOML,
SEND, SAML, VRFY, EXPN, HELP, TURN, ETRN, and XXXX.
Decode logic does not act on these commands, but does provide an
acknowledgement that the command was sent. The default is off.
• Mcast
Mcast server profile entries within the test configuration array should adhere to the
following syntax:
WrServerProfile,<ServerProfileName>,Mcast,
<Mcast Parameter> <value>

parameter must be set to Mcast. Also remember to set the <Port> parameter to
◊ <Mcast Parameter> <value>

o GroupAddress <XX.XX.XX.XX>
Enter the VOD multicast group IP address onto which you want this
server to stream data. This is the destination IP address of packets sent by
this server. The default is 225.1.1.1.
o GroupChanInc <integer>
Enter the channel increment for the group IP address (default is1). If a
range is specified, then the GroupAddress Increment specifies the incre-
mental value of the multicast group address onto which each server
streams data.
o Transport 0 | 1
Specify the transport method (default is 0):
0 - Raw UDP: The server sends raw UDP data.
1- RTP: The server streams RTP data. You might want to select RTP if
you are using the client to emulate multicast streaming clients, since RTP
data allows the client to measure stream bandwidth, packet loss rate, and
jitter.
o ContentType 0 | 1 | 2
Specify the content type (default is 2):
0 - Generate dynamically. The server generates data dynamically. The
content is unspecified.
1 - Spirent-RTP. A Spirent-proprietary format that consists of pre-formed
RTP packets. Spirent supplies several files of this format.
2 - MPEG-2. An ISO standard MPEG-2 format. MPEG-2 cannot be used
if the Transport Method is rtp.
o InterpacketMs <integer>
If you selected 0 (Generate dynamically) as the ContentType, enter the
time, in milliseconds, between sending each packet (default is100).
o PacketSize <integer>
If you selected Generate dynamically as the ContentType, enter the size of
the packets in bytes (default is1024).
o Content <filename>
If you selected Spirent-RTP or MPEG-2 as the ContentType, enter the
name of streaming file that you have loaded as a content file.The default
is an empty string.
• Streaming
Streaming server profile entries within the test configuration array should adhere
WrServerProfile,<ServerProfileName>,Streaming,<Streaming
Parameter> <value>

parameter must be set to Streaming. Also remember to set the <Port>
parameter to 554 if configuring using default values.
◊ <Streaming Parameter> <value>

o SendFeedback on | off
Enable or disable feedback. Enable so that packets include a server
transmission status report with a response. The default is off.
o MaxIdleTime <integer>
Enter the maximum idle time in seconds that you want the server to wait
before proceeding with the next stream. The default is 20.
o ServerType <integer>
Enter the server type. The default is 0.
• Telnet
Telnet server profile entries within the test configuration array should adhere to the
following syntax:
WrServerProfile,<ServerProfileName>,Telnet,
<Telnet Parameter> <value>

parameter must be set to Telnet. Also remember to set the <Port> parameter
to 23 if configuring using default values.
◊ <Telnet Parameter> <value>

o options on | off
Enable or disable open negotiation. Enable to notify the server that before
using a Telnet option, the parties must negotiate to ensure that both ends
support the option. The default is on.
o endOfLineChar None CR CR/LF
Indicate if you want to add end-of-line characters to each Telnet
command:
None – No end-of-line character
CR – Carriage Return
CR/LF – Carriage Return and Line Feed
The default is None. The GUI equivalent for this parameter is the End of
Live Sequence to Send field in the Telnet Client Information fields of the
Client Profiles tab.
o Command
◊ Telnet server profile Command parameter entries within the test configuration
WrServerProfile,<ServerProfileName>, Telnet,
Command,<Command Entry Number>,<Command Parameter>
<value>
o Command Entry Number
ServerProfileName from 0 onwards.
o <Command Parameter><value>
∇ send <command> - Enter the command that you want to send. In
the Send and Expect parameters, you can enter strings that
contain unprintable characters, such as carriage return, line feed,
backspace, tab, and so on. You must use URL-style escaping to
encode these characters in the form of %xx, where xx is the
characters hexadecimal code. For example, line feed is escaped as
%0D, backspace is escaped as %08, and so on.
∇ expect <command> - Enter the Expect command.
∇ close none | do | expect - The close command that you
specify at the end of the session should be “do” on the client side, and
“expect” on the server side, or vice-versa. Specify the type of close
command to be either none, do, or expect.
∇ timeout <integer> - Enter the time to wait after the send com-
mand.
∇ wait <integer> - Enter the time to wait after the expect com-
mand.
∇ echooff on | off - Enable or disable mode of terminals echo.
• DNS
DNS server profile entries within the test configuration array include two
parameter entries. The first entry associates user-defined zones with a server pro-
file and should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,DNS,Zones <Zone List>
◊ Zone List
A standard Tcl list (space delimited) containing the names of any defined
zones (for example, {<Zone Name1> <Zone Name2>})
The second DNS server profile entry defines the zones and their associated records
and should adhere to the following syntax:
WrDNSZone,<ZoneName>,Zone,<Zone Record Number><Record
Parameter> <Zone Value>
Note: To instigate a DNS profile within a test the <ApplicationProtocol>

parameter must be set to DNS. Also remember to set the <Port> parameter to 53
if configuring using default values.
◊ Zone Record Number

Iterates from 0 with each record created within a specific zone. The first
record created within each zone must be specified as 0.
◊ <Record Parameter> <Zone value>
o Name <string>
A user-specified name for the current record.
o Type Address | MailExchange | NameServer | Pointer |
Canonical |StartOfAuthority | AAAA
Specify the type of record:
o Class <integer>
DNS supports only the IN (Internet) class of record. The default is 1.
o TimeToLive <integer>
Amount of time (in seconds) the resource record can be stored in cache.
o Address <XX.XX.XX.XX> | <IPv6 IP>
The IP address to be mapped, in either IPv4 or IPv6 format. Use this
parameter when the type specified is Address. The default is 1.1.1.1. For a
quad A record type “AAAA,” the address format can be specified as an
IPv6 address.
o Preference <integer>
If you have several MX records for the same domain name, rank them in
order of preference. Use this parameter when the type specified is
MailExchange. The default is 0.
o MailExchange <string>
Name of the designated mail server. Use this parameter when the type
specified is MailExchange.
o NameServer <string>
Name of the host machine on which the name server is running. Use this
parameter when the type specified is NameServer.
o Domain <string>
The local IP address portion of the reverse name. Use this parameter
when the type specified is Pointer.
o PrimaryName <string>
A fully-qualified DNS name, which should be used as the target of
another DNS operation to acquire the desired information. Use this
parameter when the type specified is Canonical.
o ResponsibleAuthority <string>
The e-mail address of the person responsible for the zone. Use this
parameter when the type specified is StartOfAuthority.
o SerialNumber <integer>
The serial number of the zone file. Use this parameter when the type
specified is StartOfAuthority.
o RefreshInterval <integer>
The secondary refresh time. Use this parameter when the type specified is
StartOfAuthority.
o RetryInterval <integer>
The secondary retry time. Use this parameter when the type specified is
StartOfAuthority.
o ExpirationLimit <integer>
The secondary expire time. Use this parameter when the type specified is
StartOfAuthority.
o MinimumTimeToLive <integer>
The minimum Time To Live (TTL). Use this parameter when the type
specified is StartOfAuthority.
• MMS
With Multimedia Messaging Service (MMS), cell phone providers can send and
receive messages.
MMS server profile entries within the test configuration array should adhere to the
following syntax:
WrServerProfile,<ServerProfileName>,MMS,<MMSParameter>
<value>

parameter must be set to MMS. Also remember to set the <Port> parameter to
◊ <MMSParameter> <value>
o SendFeedback on | off
Enable or disable feedback. Enable so that packets include a server
transmission status report with a response. The default is off.
o MaxIdleTime <integer>
Enter the maximum idle time in seconds that you want the server to wait
before proceeding with the next stream. The default is 20.
• POP3
POP3 server profile entries within the test configuration array should adhere to the
following syntax:
WrServerProfile,<ServerProfileName>,POP3,Mailbox,
<Mailbox Number>,<Mailbox Parameter> <value>

parameter must be set to POP3. Also remember to set the <Port> parameter to
◊ <Mailbox Number>
Iterates with each new Mailbox definition from 0 onwards.
◊ <Mailbox Parameter> <value>
o User <string>
The mailbox name. You can enter up to 64 characters. The mailbox name
and password associated with the mailbox are the same. The default is an
empty string.
o Unavailable <integer>
The percentage of time the mailbox is unavailable, between 0 - 100. The
default is 0.
o FileListEnable 0 | 1
Enable or disable the use of Content Files. The default is 0.
o FileList,Filenumber <filename>,<filenumber>
Associate a content file with a given mailbox. The <file number>
parameter iterates with each associated file from 0.
For example, associate two files as follows:
…,FileList,0 {C:\\Attachment1.txt}
…,FileList,1 {C:\\Attachment2.txt}
o MinimumNumberOfMessages <integer>
The minimum number of messages to be generated, between 0 and 65535.
Each time there is a connection to the mailbox, a random number between
MinimumNumberOfMessages and MaximumNumberOfMessages is
used. The default is 1.
o MaximumNumberOfMessages <integer>
The maximum number of messages to be generated, between 0 and
65535. Each time there is a connection to the mailbox, a random number
between MinimumNumberOfMessages and
MaximumNumberOfMessages is used. The default is 10.
o MinimumMessageLength <integer>
The minimum size of messages to be generated, between 0 and 32767.
Each time there is a connection to the mailbox, a random message size
between MinimumMessageLength and MaximumMessageLength is
o MaximumMessageLength <integer>
The maximum size of messages to be generated, between 0 and 32767.
o RandomHeader on | off
Enable to generate a random alphanumeric string to be used as the server
name in the From and Message-ID fields. The To field is the user name
that you specify. Disable to use fixed strings in the From, To, and Mes-
sage-ID fields. The default is on.
• IMAP4
IMAP4 server profile entries within the test configuration array include three
parameter entries. The first entry defines the total number of mailboxes, and
WrServerProfile,<ServerProfileName>,IMAP4,NumberOfMail-
boxes <NumMboxes>

parameter must be set to IMAP4. Also remember to set the <Port> parameter to
◊ <NumMboxes>
The total number of mailboxes you are specifying.
The second IMAP4 server profile entry defines the mailbox name and availability
for each mailbox, and should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,IMAP4,Mailbox,
<Mailbox Number>,<Mailbox Parameter> <value>
◊ <Mailbox Parameter> <value>
o User <string>
The mailbox name. You can enter up to 64 characters. The mailbox name
and password associated with the mailbox are the same. The default is an
empty string.
o Unavailable <integer>
The percentage of time the mailbox is unavailable, between 0 - 100. The
default is 0.
The third IMAP4 server profile entry defines the mailbox folders for each mail-
box, and should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,IMAP4,Mailbox,
<Mailbox Number>,Folder,<Folder Number>,<Folder Parame-
ter> <value>
◊ <Folder Number>
Iterates with each new Folder definition from 0 onwards.
◊ <Folder Parameter> <value>
o FolderPath <string>
The folder name, such as “Inbox” or “Saved Messages.”
o MinimumNumberOfMessages <integer>
The minimum number of messages to be generated, between 0 and 65535.
Each time there is a connection to the mailbox, a random number between
MinimumNumberOfMessages and MaximumNumberOfMessages is
o MaximumNumberOfMessages <integer>
The maximum number of messages to be generated, between 0 and
65535. Each time there is a connection to the mailbox, a random number
between MinimumNumberOfMessages and
MaximumNumberOfMessages is used. The default is 10.
o MinimumMessageLength <integer>
The minimum size of messages to be generated, between 0 and 32767.
o MaximumMessageLength <integer>
The maximum size of messages to be generated, between 0 and 32767.
• CapRepTCP
If a PCap file WILL NOT BE uploaded, Capture/Replay TCP server profile
entries within the test configuration array should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,CapRepTCP,
<ActionNumber> <CapRep Parameter> <value>

parameter must be set to CapRepTCP. Also remember to set the <Port>
◊ <ActionNumber>
Iterates with each new individual action from 0 onwards.
◊ <CapRep Parameter> <value>
o Type <action_type>
The type of capture replay action required. See Table 3-1, “Capture
Replay Action Type List,” on page 107, for a list of acceptable action
types.
o Value <value>
The value associated with the current action. Enter an argument for the
action type that you entered in the Type parameter. When entering send
and expect action types, you can specify strings that contain unprintable
characters, such as, carriage return, line feed, backspace, tab, and so on.
You must use URL-style escaping to encode these characters in the form
of %xx, where xx is the character’s hexadecimal code. For example, line
feed is escaped as %0D, backspace is escaped as %08, and so on
o Min <integer>
Enter a minimum value if an applicable action type is chosen. See
Table 3-1, “Capture Replay Action Type List,” on page 107, for a list of
o Max <integer>
Enter a maximum value if an applicable action type is chosen. Table 3-1,
“Capture Replay Action Type List,” on page 107, for a list of acceptable
action types.
If a PCap file WILL BE uploaded, Capture/Replay TCP server profile entries
within the test configuration array should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,CapRepTCP,
<CapRep Parameter> <value>

parameter must be set to CapRepTCP. Also remember to set the <Port>

o PcapFile <string>
Enter the name of the capture file (for example, http.pcap), that you
loaded as a content file. This file must be libpcap-compatible, such as that
generated by Ethereal or tcpdump or CAP files created using Network
Associates Sniffer 2.00x program.
o DestHost <X.X.X.X>
Enter the IP address of the actual server in the capture traffic.
If you don't use the AutoDiscover option, use the DestHost and
DestPort parameters to uniquely identify the resulting session to be
taken from the capture file. These values, along with the type (TCP or
UDP), filter packets in the file. (Alternatively, if you use the
AutoDiscover option, the client automatically searches the uploaded
file and identifies the start of the conversation.)
For TCP, the first TCP packet that is a SYN packet having the specified
destination IP address and port is found. The source IP address and port of
this packet, along with the configured destination IP address and port, are
uniquely identify the resulting session. If there are several TCP sessions
with the specified destination server in the same capture file, the client
uses only the first one as the resulting session.
The client ignores Retransmit packets. When the FIN packet is found, the
client inserts a close command in the resulting session, with
parameters based on the side that sent the FIN.
Note: If the resulting session closed with an RST, the client marks it
successful.
o DestPort <integer>
Enter the port of the actual server in the capture traffic.
o AutoDiscover true | false
Enter “true” to have the client search the uploaded capture file and locate
the TCP/UDP session to use, identifying the start of the
conversation. If you specify this option, then the Destination host
(DestHost) and Destination port (DestPort) parameters are not
required and thus not available.
o PreserveDelay true | false
milliseconds in the capture file.
• CapRepUDP
If a PCap file WILL NOT BE uploaded, Capture/Replay UDP server profile
entries within the test configuration array should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,CapRepUDP,
<ActionNumber> <CapRep Parameter> <value>

parameter must be set to CapRepUDP. Also remember to set the <Port>
◊ <ActionNumber>
Iterates with each new individual action from 0 onwards.
The type of capture replay action required. See Table 3-1, “Capture
Replay Action Type List,” on page 107, for a list of acceptable action
types.
o Value <value>
o Min <integer>
Table 3-1, “Capture Replay Action Type List,” on page 107, for a list of
o Max <integer>
Enter a maximum value if an applicable action type is chosen. Table 3-1,
“Capture Replay Action Type List,” on page 107, for a list of acceptable
action types.
If a PCap file WILL BE uploaded, Capture/Replay UDP server profile entries
WrServerProfile,<ServerProfileName>,CapRepUDP,

parameter must be set to CapRepUDP. Also remember to set the <Port>

o PcapFile <string>
Enter the IP address of the actual server in the capture traffic.
If you don't use the AutoDiscover option, use the DestHost and
DestPort parameters to uniquely identify the resulting session to be
taken from the capture file. These values, along with the type (TCP or
UDP), filter packets in the file. (Alternatively, if you use the
AutoDiscover option, the client automatically searches the uploaded
file and identifies the start of the conversation.)
For UDP, the first UDP packet that has the specified destination IP
address and port is found. The source IP address and port of this packet,
along with the configured destination IP address and port, are used to
uniquely identify the resulting session. If there are several UDP sessions
with the specified destination server in the same capture file, the client
uses only the first one as the resulting session.
The client ignores Retransmit packets. When the FIN packet is found, the
client inserts a close command in the resulting session, with
parameters based on the side that sent the FIN.
Note: If the resulting session closed with an RST, the client marks it
successful.
Enter the port of the actual server in the capture traffic.
Enter “true” to have the client search the uploaded capture file and locate
the TCP/UDP session to use, identifying the start of the
required and thus not available.
• Preserve inter-packet delay. Enter “true” if you want the client
milliseconds in the capture file.
• Capture/Replay Eth Server Profile Parameters
If a PCap file WILL NOT BE uploaded, Capture/Replay Eth server profile entries
WrServerProfile,<ServerProfileName>,CapRepEth,
parameter must be set to CapRepEth. Also remember to set the <Port>
The type of capture replay action required. See Table 3-1 on page 107, for
a list of acceptable action types.
o Value <value>
o Min <integer>
Table 3-1 on page 107, for a list of acceptable action types.
o Max <integer>
Enter a maximum value if an applicable action type is chosen. See
Table 3-1 on page 107, for a list of acceptable action types.
o First <XX:XX:XX:XX:XX:XX>
Enter the first gateway MAC address for the client. This parameter is
applicable only when the action type is “routing.”
o Last <XX:XX:XX:XX:XX:XX>
Enter the last gateway MAC address before the server. This parameter is
applicable only when the action type is “routing.”
If a PCap file WILL BE uploaded, Capture/Replay Eth server profile entries
WrServerProfile,<ServerProfileName>,CapRepEth,

parameter must be set to CapRepEth. Also remember to set the <Port>
o PcapFile <string>
Enter the IP address of the actual server in the capture traffic only if you
specified a Pcap file.
Enter the port of the actual server in the capture traffic only if you speci-
fied a Pcap file.
Enter “true” to have the client search the Pcap file and locate the TCP/
UDP session to use, identifying the start of the
required and thus not available. The default value is false.
milliseconds in the Pcap file. The default value is false.
• SIPUDP
SIP (Session Initiation Protocol) is an application-layer control protocol that can
establish, modify, and terminate multimedia sessions (conferences) such as Inter-
net telephony calls.
Use the SIP server profiles parameters to configure information for a SIP server.
the client supports SIP over UDP and TCP transport modes. RTP data streams are
used to emulate the real IP telephony traffic.
SIP UDP server profile entries within the test configuration array should adhere to
WrServerProfile,<ServerProfileName>,SIPUdp,
<SIP Parameter> <value>
parameter must be set to SIP UDP. Also remember to set the <Port> parameter
◊ <SIP Parameter> <value>

o ConnectionPort <integer>
Enter the port where the server resides. The default port is 5060.
o RTPFirstPort <integer>
Enter the port number on which the first RTP listeners will be created.
The value should be even and in the acceptable port range. The port value
is incremented by 2 for each additional RTP channel. The default port is
10000.
o NumOfRTPListeners <integer>
Note: In the current release, the number of channels can be less than the
maximum number of simultaneous calls, since the channel can be reused
by different calls. However, this may be changed in a future release. It is
recommended that you set the number of channels to be greater than the
expected maximum number of simultaneous calls to provide more realis-
tic traffic.
o BusyCallProbability <integer>
Enter the probability (percentage) that incoming calls will be rejected by
the server. The default is 0.
o EndCallTimeout <integer>
Enter the amount of time in milliseconds to handle the call if the call was
not terminated by the client. The default is 180000 milliseconds.
o OffHookMinTime <integer>
The timeout after which the server picks up the call is randomly chosen
between the minimum off-hook time and the maximum off-hook time
(below). The default minimum off-hook time is 20000 milliseconds.
Before the timeout expires, the ringing signal is sent to the caller.
o OffHookMaxTime <integer>
between the minimum off-hook time (above) and this maximum off-hook
time. The default maximum off-hook time is 20000 milliseconds.
• SIPTCP
Use the SIP server profile parameters to configure information for a SIP (Session
Initiation Protocol) server. SIP is an application-layer control protocol that can
establish, modify, and terminate multimedia sessions such as Internet telephony
calls. Transport modes supported for SIP include UDP and TCP. RTP data streams
are used to emulate the real IP telephony traffic.
SIP TCP server profile entries within the test configuration array should adhere to
WrServerProfile,<ServerProfileName>,SIPTcp,
<SIP Parameter> <value>

parameter must be set to SIP TCP. Also remember to set the <Port> parameter
◊ <SIP Parameter> <value>

o ConnectionPort <integer>
Enter the port where the server resides. The default port is 5060.
o RTPFirstPort <integer>
Enter the port number on which the first RTP listeners will be created.
The value should be even and in the acceptable port range. The port value
is incremented by 2 for each additional RTP channel. The default port is
10000.
o NumOfRTPListeners <integer>
Note: In the current release, the number of channels can be less than the
maximum number of simultaneous calls, since the channel can be reused
by different calls. However, this may be changed in a future release. It is
recommended that you set the number of channels to be greater than the
expected maximum number of simultaneous calls to provide more realis-
tic traffic.
o BusyCallProbability <integer>
Enter the probability (percentage) that incoming calls will be rejected by
the server. The default is 0.
o EndCallTimeout <integer>
Enter the amount of time in milliseconds to handle the call if the call was
not terminated by the client. The default is 180000 milliseconds.
o OffHookMinTime <integer>
between the minimum off-hook time and the maximum off-hook time
(below). The default minimum off-hook time is 20000 milliseconds.
o OffHookMaxTime <integer>
between the minimum off-hook time (above) and this maximum off-hook
time. The default maximum off-hook time is 20000 milliseconds.
• MM4
Use the MM4 server profile parameters to emulate a recipient Multimedia Mes-
saging Service (MMS) Relay/Server. Each MM4 message is sent by using a sepa-
rate SMTP session on the client and server. For more information about the role of
the client and server and the requests and responses generated, see the Layer 4-7
Application online help.
MM4 server profile entries within the test configuration array should adhere to the
following syntax:
WrServerProfile,<ServerProfileName>,MM4,<MM4 Parameter>
<value>

parameter must be set to MM4. Also remember to set the <Port> parameter to
◊ <MM4 Parameter> <value>

o OriginatorPort <integer>
Enter the client port number that accepts MM4 messages from the server.
The default port is the SMTP port, 25. The port you specify here must be
the same port specified in the Mm4OriginatorPort parameter defined
in the User Profile.
o SystemAddress <email address>
Specify the system email address of the recipient Multimedia Messaging
Service Center (MMSC). The default email address is recipi-
[email protected].
o ResponseTimeout <integer>
Specify, in milliseconds, the amount of time to wait for an MM4 response
from the client. The default is 1000 milliseconds.
o MinMmscRequestTimeout <integer>
Specify, in milliseconds, the minimum delay time before sending an
MM4_delivery_report.REQ message to the client. The default is 1000
milliseconds.
o MaxMmscRequestTimeout <integer>
Specify, in milliseconds, the maximum delay time before sending an
MM4_delivery_report.REQ message to the client. The default is 1000
milliseconds.
o MinUserRequestTimeout <integer>
Specify, in milliseconds, the minimum delay time before sending an
MM4_read_reply_report.REQ message to the client. The default is 0 mil-
liseconds.
o MaxUserRequestTimeout <integer>
Specify, in milliseconds, the maximum delay time before sending an
MM4_read_reply_report.REQ message to the client. The default is 3 mil-
liseconds.
o DenyDeliveryReportPercentage <integer>
Specify the percentage of delivery_report requests the server denies from
the client. Enter a value of 0 - 100. For example, if you do not want the
server to send any delivery report requests, enter 100 so that 100% of the
requests are denied. The default is 0.
o DenyReadReplyReportPercentage <integer>
Specify the percentage of read_reply_report requests the server denies
from the client. Enter a value of 0 - 100. For example, if you want the
server to always send read reply report requests, enter 0 so that 0% (that
is, none) of the requests are denied. The default is 0.
o AckDeliveryReportPercentage <integer>
Specify the percentage of MM4_delivery_report.RES messages in
response to a MM4_delivery_report.REQ received from the server. Enter
a value of 0 - 100. The default is 100.
o AckReadReplyReportPercentage <integer>
Specify the percentage of MM4_read_reply_report.RES messages that
the client sends in response to a MM4_read_reply_report.REQ received
from the server. Enter a value of 0 - 100. The default is 100.
• MM4 Server Profile RequestStatusPercentage Parameters
Use the MM4 server profile Request Status Percentage parameters to determine
the percentage of each request status used for random selection in
MM4_forward.RES.
MM4 server profile RequestStatusPercentage parameter entries within the test
WrServerProfile,<ServerProfileName>,MM4,RequestStatusPer-
centage, <Parameter> <value>
Note: The sum of all of the following options should equal 100.
Specifies the parameter (that is, request statuses) as one of the following val-
ues:
o OK <integer>
Specify the random selection percentage for “OK” as the request status
used in MM4_forward.RES. The default is 100.
o Unspecified <integer>
Specify the random selection percentage for “Error-unspecified” as the
request status used in MM4_forward.RES. The default is 0.
o ServiceDenied <integer>
Specify the random selection percentage for “Error-service-denied” as the
request status used in MM4_forward.RES. The default is 0.
o MessageFormatCorrupt <integer>
Specify the random selection percentage for “Error-message-format-cor-
rupt” as the request status used in MM4_forward.RES. The default is 0.
o SendingAddressUnresolved <integer>
Specify the random selection percentage for “Error-sending-address-unre-
solved” as the request status used in MM4_forward.RES. The default is 0.
o MessageNotFound <integer>
Specify the random selection percentage for “Error-message-not-found”
as the request status used in MM4_forward.RES. The default is 0.
o NetworkProblem <integer>
Specify the random selection percentage for “Error-network-problem” as

the request status used in MM4_forward.RES. The default is 0.
o ContentNotAccepted <integer>
Specify the random selection percentage for “Error-content-not-accepted”
as the request status used in MM4_forward.RES. The default is 0.
o UnsupportedMessage <integer>
Specify the random selection percentage for “Error-unsupported-mes-
sage” as the request status used in MM4_forward.RES. The default is 0.
• MM4 Server Profile MessageStatusPercentage Parameters
Use the MM4 server profile Message Status Percentage parameters to determine
the percentage of each message status used for random selection in
MM4_delivery_report.REQ.
MM4 server profile MessageStatusPercentage parameter entries within the test
WrServerProfile,<ServerProfileName>,MM4,MessageStatusPer-
Specifies the parameter (that is, message statuses) as one of the following val-
ues:
o Expired <integer>
Specify the random selection percentage for “Expired” as the message
status used in MM4_delivery_report.REQ. The default is 0.
o Retrieved <integer>
Specify the random selection percentage for “Retrieved” as the message
o Deferred <integer>
Specify the random selection percentage for “Deferred” as the message
o Indeterminate <integer>
Specify the random selection percentage for “Indeterminate” as the mes-
sage status used in MM4_delivery_report.REQ. The default is 0.
o Forwarded <integer>
Specify the random selection percentage for “Forwarded” as the message
o Unrecognized <integer>
Specify the random selection percentage for “Unrecognized” as the mes-
sage status used in MM4_delivery_report.REQ. The default is 0.
• MM4 Server Profile ReadStatusPercentage Parameters
Use the MM4 server profile Read Status Percentage parameters to determine the
percentage of each read status used for random selection in
MM4_read_reply_report.REQ.
MM4 server profile ReadStatusPercentage parameter entries within the test con-
figuration array should adhere to the following syntax:
WrServerProfile,<ServerProfileName>,MM4,ReadStatusPer-
Specifies the parameter (that is, request statuses) as one of the following val-
ues:
o Read <integer>
Specify the random selection percentage for “Read” as the read status
used in MM4_read_reply_report.REQ. The default is 100.
o DeletedWithoutBeingRead <integer>
Specify the random selection percentage for “Deleted Without Being
Read” as the read status used in MM4_read_reply_report.REQ. The
default is 0.
• NoClose on | off
Enable or disable the closure of TCP connections. HTTP keeps the TCP
connections open. It is recommended that you do not enable this option. If
enabled, all the TCP connections remain open until the end of the test, and the
system's resources will be depleted. This option is available so that network
devices, such as load balancers, can be tested against the number of connections
advertised by the manufacturer. Maintaining the open connection allows you to
run tests using the minimum amount of bandwidth, avoiding the overhead
associated with TCP connection teardown. The default is off.
• IgnoreArp on | off
Specify whether you want to ignore ARP requests. The default is off. Enable this
option if you want any IP address associated with the server to ignore ARP
(Address Resolution Protocol) requests. This IP address will however, accept
packets from the network.
This option allows an SLB (Server Load Balancer) to match the IP address to the
VIP (virtual IP address) for the server on the SLB. An HTTP client sends an HTTP
request to the VIP on the SLB, and the SLB forwards the unmodified request to
the same address on the server. The HTTP response from the server goes directly
back to the client address specified in the unmodified HTTP request.
If you enable this option, a client cannot resolve the server IP address to a MAC
address. This lets the SLB handle the ARP on behalf of the server and receive IP
traffic directed to the server. Without an SLB or similar device, the server cannot
be reached.
Important: If a server is configured to ignore ARP, all other servers at the same IP
address, but with different ports, will ignore ARP.
• CloseOption Immediate | Never |AfterTimeout
Specify the method that you want the server to use to initiate an HTTP close
connection. The default is Immediate.
◊ Immediate
HTTP closes the TCP connection as soon as it completes all transactions for
the connection. This is the default setting.
◊ Never
HTTP keeps the TCP connections open. It is recommended that you do not
select this checkbox. If checked, all the TCP connections remain open until
the end of the test, and the system's resources will be depleted. This option is
available so that network devices, such as load balancers, can be tested against
the number of connections advertised by the manufacturer. Maintaining the
open connection allows you to run tests using the minimum amount of band-
width, avoiding the overhead associated with TCP connection teardown. This
is the default setting.
◊ AfterTimeout
HTTP waits until the time that you specify in the CloseTimeout parameter,
and then it closes the connection.
Note: This option is only enabled when configuring an HTTP server (that is,
<ApplicationProtocol> = HTTP).
The GUI equivalent for this parameter is the Connection Termination field in of
the Server Profile HTTP tab.
• CloseMethod RST | FIN
Specify the method to use to complete the closure:
◊ RST - abort connection. This is the default option.
◊ FIN - close connection
The GUI equivalent for this parameter is the Close Connection Method field on the
Server Profile HTTP tab.
• CloseTimeout <integer>
If you selected the AfterTimeout option for the CloseMethod parameter,
enter a value between 1 and 60,000ms to indicate how long HTTP should wait
before closing the connection.
The GUI equivalent for this parameter is the Close Timeout field in of the Server
Profile HTTP tab.
• ToS <integer>
Enter the Type of Service (ToS) value. The ToS value is any number between 0
and 255 that is inserted in the IP header of all outgoing segments from the subnet.
To disable the ToS, you may enter an empty value. When the ToS is disabled, the
API uses the subnet settings. The default is empty or disabled.
• EnableGre on | off
Enable or disable the Generic Router Encapsulation (GRE) for the server profile.
Enable this option only when the server is terminating the GRE tunnel. Routers
use GRE to “bridge” two networks. The GRE protocol specifies a point-to-point
session using IP datagrams addressed between two routers (that is, routers config-
ured as virtual routers). When enabled, GRE encapsulation is used for traffic leav-
ing clients and servers for a given transaction. You cannot enable/disable
checksums and enable/disable sequence numbers. In addition, ACK and sliding-
window support, and PPTP headers are not supported. The default is off.
WrTransactionProfile
Usage Use the Transaction Profile parameters to configure the HTTP/HTTPS server transactions
for tests.
Syntax WrTransactionProfile,<TransactionProfileName>,<Parameter>
<value>
• <TransactionProfileName>
The name of the HTTP/HTTPS server you are configuring.
Provide a description of the current test.
• TransactionId <integer>
Enter the ID number of the transaction. The default is 1024.
• StatusCode <integer>
Enter an HTTP response status code between 100 and 599 that you want
the server to send in response to requests.
• StatusPhrase <string>
Displays the corresponding phrase for the Status Code specified in the
StatusCode parameter. The default is OK.
• BodyBytes <integer>
Define the response's body size in bytes. This includes the size of the body of the
returned page, which is equivalent to a Web page, a graphic, and so on. The total
response size is this value, plus the size of the headers sent. Enter a value between
0 and 10,000,000.
• BodyMean <integer>
Determine the mean for all body sizes used, which is calculated by dividing the
sum of all body sizes by the number of body sizes. Enter an average HTTP
response body size in bytes.
• BodySD <integer>
Define the level of deviation from the mean value entered as the size mean. This
parameter allows specifying how close all the body sizes used by the server are to
the mean body size. A small standard deviation means the server generates bodies
that are relatively close in size, while a large standard deviation creates body sizes
that are more varied. Enter an amount that indicates how much you want the aver-
age body size to vary.
• BodyString <string>
Specify the text to embed in the HTTP response body. Use BodyString when
BodyStringType is set to 2 (Fixed Text). The default is “Spirent
Communications.”
• BodyStringPosition 1 | 2 | 3
Specify the position of the text in the HTTP response body. The default is 1.
1- Beginning
2- Middle
3- End
• BodyStringRandomBytes <integer>
This feature is enabled when BodyStringType is set to 3 (Random Text). The
default is 3. Its GUI equivalent is the Random Text of Length field.
• BodyStringType 1 | 2 | 3
Specify the type of text to embed in the HTTP response body. The default is 1. Its
GUI equivalent is the Embedded String field
1 - Empty: Adds no embedded string in the HTTP response body.
2 - Fixed Text: The text that you enter for the BodyString parameter specifies
the text to embed in the HTTP response.
3 - Random Text: Tells the server to add random text of a specified length in the
response body. You enter the length in the BodyStringRandomBytes
parameter. You also specify where (beginning, middle, or end) to embed the string
in the HTTP response body by specifying an option for the
BodyStringPosition parameter.
• ContentMD5HeaderEnabled on | off
Enable of disable Content-MD5 headers. The default is off.
• ContentMD5HeaderInterval <integer>
Enter the interval in milliseconds between each successive generation. The default
is 1000.
• DataType 1 | 2 | 3 | 4
Specify a body data type for use with the data that you want the server to send in
response to a user request. The associated parameters that you must provide
depends on the DataType that you specify:
1 - Ascii: The server uses the string information that you specify in the
BodyStringType parameter.
2 - Binary: The server determines the contents of the response body.
3 - File: The server uses the file that you specify in the BodyFilename parame-
ter.
4 - Files From Directory: The server uses the file name that you specified in the
FileHierarchy parameter and the file directory that you specified in the
FilesFromDirectory (see page 173). This file hierarchy is treated as a single
transaction profile.
• MIMEType “text/html”
Define the MIME (Multipurpose Internet Mail Extensions) type used in the HTTP
Content-Type header. The MIME Type's Magic Bytes are also added to the binary
data response. See Table 3-2, “Valid MIME Types,” on page 175, for a list of
acceptable MIME types.
• Latency <integer>
Enter the time delay that the server waits in milliseconds before sending a
response. The maximum value that you can enter is 120,000 milliseconds (ms).
The delay begins after the server receives an HTTP request, for example, after a
GET. The default is 0.
• LatencyMean <integer>
Enter the average time in milliseconds you want to wait before returning an HTTP
Response. This value determines the mean of all the latency times recorded. The
mean is calculated by dividing the sum of all the latency times by the number of
latencies observed. The default is 0.
• LatencySD <integer>
Enter a value that indicates how much you want the average latency to vary. This
defines the standard deviation of all latency times observed. The standard devia-
tion defines how close the latency times used by the server are to the mean latency
time. A small standard deviation generates latency times that are not very differ-
ent, while a large standard deviation tells the server to generate times that are quite
varied. The default is 0.
• LastModifiedHeader <formatted string>
Specify the last time that the URL resource was requested, and tell the cache
server if the resource has changed. This feature is particularly useful when testing
the behavior of cache devices. The associated parameters that you must provide
depend on the value you specified for the LastModifiedHeaderProgram
parameter. The default is "Mon, 01 Jan 2001 00:00:17 GMT."
The format of this entry must be as follows:
<day>, <date> <time> <zone>
For example:
Thu, 06 May 2004 01:02:03 GMT
• LastModifiedHeaderProgram 1 | 2 | 3
Specify the last modified header type:
1 - None: Turns off the LastModifiedHeader feature. If your test does not
involve the use of cache devices, it is suggested that you specify None.
2 - Fixed: Specify a fixed timestamp that is sent on the LastModifiedHeader every
time the server serves the transaction. If you specify this option, you must also
specify parameter values for LastModifiedHeaderProgramStart and
LastModifiedHeaderProgramEnd.
3 - Variable: Specify a range of time used for the LastModifiedHeader. Every
time the server responds to a transaction, it checks the values entered here, and
generates a timestamp. If you specify this option, you must also specify parameter
values for:
LastModifiedHeaderProgramStart (start date and time),
LastModifiedHeaderProgramEnd (end date and time),
LastModifiedHeaderProgramSeconds (increment amount), and
LastModifiedHeaderProgramPercent (increment frequency).
The default is 1.
• LastModifiedHeaderProgramStart <formatted string>
Specify a start date and time. The default is "Mon, 01 Jan 2001 00:00:17 GMT."
For example:
Thu, 06 May 2004 01:02:03 GMT
• LastModifiedHeaderProgramEnd <formatted string>
Specify an end date and time. The default is "Tue, 30 Jan 2001 00:00:00 GMT""
For example: Thu, 06 May 2004 01:02:03 GMT
• LastModifiedHeaderProgramSeconds <integer>
Tells the server how long (in seconds) to increment the timestamp of the Last
Modified header sent back. This increment is added according to the Increment
Frequency variable. The default is 60.
• LastModifiedHeaderProgramPercent <integer>
Tells the server how frequently to increment the timestamp. If set to 100%, it will
increment the timestamp according to the increment amount
(LastModifiedHeaderProgramSeconds) specified every time the
transaction is served to the cache server. The default is 25.
• ExtendedHttpHeaders <string>
Provides a timestamp that tells the cache server to update the resource. The
associated parameters that you must provide depend on your selection for the
ExpiresHeaderProgram parameter.
• ExpiresHeaderProgram 1 | 2 | 3 | 4
Specify the expired header type. The default is 1.
1 - None: Turns off the Expires feature. If your test does not involve the use of
cache devices, it is suggested that you specify None.
2 - Fixed: Specify a fixed timestamp that is sent in the Expires header every time
the server serves the transaction. If you specify this option, you must also specify
parameter values for LastModifiedHeaderProgramStart and
LastModifiedHeaderProgramEnd.
3 - Uniform Distribution: If you specify this option, you must also specify param-
eter values for ExpiresHeaderUniformStartSeconds and Expires-
HeaderUniformEndSeconds to select a uniform distribution to generate an
offset (time difference) from the Last Modified time. A uniform distribution has
the same probability for all the members of the population, which means the server
selects an offset from the range specified when sending the transaction back to the
server, and every number in the range has the same probability of being selected.
4 - Normal Distribution: If you specify this option, you must also specify
parameter values for ExpiresHeaderNormalMeanSeconds and
ExpiresHeaderNormalSDSeconds to select a normal distribution as the
means to generate an offset (time difference) from the Last Modified time. A
normal distribution, often referred to as a Bell Curve, has a concentration of mem-
bers around the middle and less on the tails of the curve. Every normal distribution
has a mean and a standard deviation that shows how much the values deviate from
the mean. The server uses the values specified here to create a normal distribution,
which in turn is used to select an offset.
• ExpiresHeader <formatted string>
Specify a start date and time. The default is "Mon, 01 Jan 2001 00:00:17 GMT"
For example: Thu, 06 May 2004 01:02:03 GMT
• ExpiresHeaderUniformStartSeconds <integer>
Determine the lower bound for the uniform distribution. The default is 1.
• ExpiresHeaderUniformEndSeconds <integer>
Determine the upper bound for the uniform distribution. The default is 1000.
• ExpiresHeaderNormalMeanSeconds <integer>
Determine the number of seconds used as the mean number for the normal
distribution. Use this parameter when ExpiresHeaderProgram is specified as
4 (Normal Distribution). The default is 1000.
• ExpiresHeaderNormalSDSeconds <integer>
Determine the number of seconds that the data in the distribution deviates from the
mean. The default is 1.
• BodyFilename <filename>
If the DataType tag in not equal to 1, the body filename parameter is set to a
filename in the wrhttpbodies directory. BodyFilename does not include
the.xml extension.
• BodyDL <Loadable Size Distribution Name>
Enables you to specify a list containing different body sizes. The server uses this
list as the source for body sizes.
• BodyContentFileLocation <file path>

Specify the location of the HTTP Response Body Content file to be incorporated
within the test, for example, {c:\\content\\test.jpg}. This parameter is
only used when the DataType parameter is set to 3.
• BodyContentAlwaysInMemory on | off
Enable or disable maintaining the HTTP body file in memory. To specify that the
HTTP body file always be maintained in memory, enter on. If you enter off, the
file can be swapped from disk as needed. The default is on.
• EncodeFileContent yes | no
Enable or disable Base64 encoding of content files. Use this parameter only when
you specify 3 (File) for the DataType parameter. A test will not run if the content
file is not Base64 encoded, so only disable this parameter if the referenced file has
already been Base64 encoded. The default is yes.
• BinaryTextFileLocation <file path>
Specify the location of the file containing the HTTP Response Body Content fixed
text string to be incorporated within the test, for example, {c:\\con-
tent\\string.txt}. This parameter is only used when the DataType param-
eter is set to 2.
• FileHierarchy <string>
• Specify a File Hierarchy name. If you specified 4 as the value of the
DataType parameter (see page 169), you must use this parameter along
with the FilesFromDirectory parameter (see below).
Note: The FileHierarchy and FilesFromDirectory parameters enable

you to upload the contents of a directory (per transaction profile) that contains a
file hierarchy. The hierarchy of files is treated as a single transaction profile so you
do not have to specify a virtual path for each file in the hierarchy.
• FilesFromDirectory <directory path>

Specify the explicit path to the directory to include with your test. If you specified
4 as the value of the DataType parameter (see page 169), you must use this
parameter along with the FileHierarchy parameter (see above).
• FullyQualifiedPath <string>
Specify the fully qualified path for the specified BodyFilename.
A fully qualified path must begin with a forward slash (/) and include alpha-
numeric and forward slash (/) characters only; Commander doesn't support URL
encoding. Do not include the host name.
Example: /upload/default.htm
Fully qualified path names are case insensitive.
A fully qualified path allows you to assign the Transaction Profile to a specific
HTTP or HTTPS response. For example, when a real content file is uploaded, it
can be associated with one or more paths on the server. Then the real content file
will be associated with the fully qualified name, and a third-party HTTP client (or
Avalanche) will get real HTTP behavior from the server.
When the server receives a request from any HTTP client that contains a fully
qualified path, the generated response is determined by the Transaction Profile that
contains that fully qualified path. If there is no Transaction Profile with the fully
qualified path as specified in the URL, the server’s default Transaction Profile is
used. If a URL request is received that references both a Transaction Profile and a
fully qualified path name, the name of the Transaction Profile takes precedence.
• AsciiTextFileLocation <file path>
Specify the location of a file containing an HTTP Response Body Content fixed
text string which is to be incorporated within the test. This parameter is only used
when <DataType> is set to 1 (for Ascii). For example:
AsciiTextFileLocation {c:\\content\\ascii.txt }
Note: The content of the specified file is inserted in its into the <BodyString>
parameter.
Table 3-2 contains a list of valid MIME types.
Table 3-2. Valid MIME Types
Valid MIME Types
application/dbm application/x-debian-package application/x-lharc
application/java application/x-dvi application/x-perl
application/msword application/x-elc application/x-realaudio
application/octet-stream application/x-executable application/x-rpm
application/pdf application/x-frame application/x-sc
application/postscript application/x-gawk application/x-shellscript
application/x-archive application/x-gdbm application/x-src
application/x-awk application/x-gzip application/x-tex-tfm
application/x-compress application/x-kdelnk application/x-zip
application/x-cpio application/x-lha application/xmcd
audio/basic audio/mpeg audio/unknown
audio/x-adpcm audio/x-aiff audio/x-msvideo
audio/x-ogg audio/x-wav image/bmp
image/gif image/jpg image/png
image/tiff image/unknown image/x-3ds
image/x-niff image/x-portable-bitmap image/x-portable-greymap
image/x-portable-pixmap image/x-xpm message/news
message/rfc822 text/html text/plain
text/rtf video/avi video/flc
video/fli video/mpeg video/quicktime
video/sgi video/unknown video/x-mng
WrContent
Usage Use the Server Content Upload parameters to upload content files to the server side.
Syntax WrContent,<File Number> <File Location>
• <File Number>
Iterates with each new content file from 0 onwards. Each content file must have an
associated file number. For example, to upload two separate files, use the following
parameters:
WrContent,0 { C:\\Content\\Movie1.mov}
WrContent,1 { C:\\Content\\Movie2.mov}
• <File Location>
The full path and name of the content file.
WrCertificate
Usage Use the WrCertificate parameters to upload SSL Authority and Revocation List Certificate
files to a server. To upload a certificate to the server, use the following syntax:
Syntax WrCertificate,<Certificate Type>,<File Number><File Location>

• <Certificate Type>
The type of certificate: Authority or Revocation.
• <File Number>
An iterative index starting at 0, incrementing with each new certificate file from 0
onward.
• <FileLocation
The full path and name of the certificate file to upload.
Note: Uploading a server certificate is handled through the use of the SSLConfig
attributes in the server profile. See HTTPS on page 143 for more information.
Each Certificate file must have an associated <Certificate Type> and
<File Number>. The following example uploads two different Authority and
two different Revocation certificates:
WrCertificate,Authority,0{C:\\Certificates\\serverauthority0.pem}
WrCertificate,Authority,1{C:\\Certificates\\serverauthority1.pem}
WrCertificate,Revocation,0{C:\\Certificates\\servercrl0.pem}
WrCertificate,Revocation,1{C:\\Certificates\\servercrl1.pem}
Clustered Test Configuration Array Parameters
Clustered Test Configuration Array Parameters

All of the client and server parameters described in the previous two sections are
applicable for both clustered test configurations and single unit test configurations;
however, there is one important parameter syntax difference: when creating clustered test
configurations, you must specify the number of units in the cluster.
Test Profile Interface Parameters

Test profile entries for a clustered test within the test configuration array should adhere to
WaTestProfile,Unit<N>,Interface,<InterfaceID>,<Parameter><value>
WrTestProfile,Unit<N>,Interface,<InterfaceID>,<Parameter><value>
• Unit <N>
An integer value within the range 0 - <number of units in cluster>, indicating the
location of the unitID within the cluster which is associated with this interface.
Specifying 0 associates the interface configuration parameters with the first unitID
encountered within the created cluster. Specifying 1 associates the interface
configuration parameters with the second unitID encountered within the created
cluster, and so on.
For example, the following script shows how to create a client cluster with four unit
IDs for appliances:
#
# Create Client Cluster
#
set clientUnits [list]
lappend clientUnits "10.47.40.17;1"
set clientClusterID [SPI_AV::ClusterController::CreateCluster "cli-
ent" "MyClientCluster" $clientUnits]
Then, specifying Unit0 will associate the interface configuration with the first client
unit in the clientUnits list (10.47.40.17;1), Unit1 with the second
(10.47.40.18;0), Unit2 with the third, and finally Unit3 with the fourth.
This facilitates the configuration of a completely generic test configuration array
which can be applied to different hardware configurations by simply modifying the
current cluster (that is, using the cluster maintenance functions DeleteCluster,
AddUnitToCluster, RemoveUnitFromCluster, and CreateCluster).
• <InterfaceID>
An integer within the range 0 - 3, depending upon the total number of available
interfaces on the appliance or Spirent TestCenter chassis.
Global Test Configuration Array Parameters

This section contains parameters that affect all devices within a test.
The following parameters are described in this section:
• Global
Global
Usage Global test profile parameters enable you to configure a system-wide delay in starting
tests to compensate for link negotiation delays that may occur with your device under test
(DUT). You configure parameters to be applied globally across the test, prior to running
the test.
These entries are equivalent to setting parameters in the Run Configure tab of the Layer 4-
7 Application.
Syntax Global,<Parameter> <value>
• StartTestDelay {<integer>}
Specify the delay value in seconds. The default delay value is 50 seconds. This
delay time is used to postpone the start of tests, allowing the NIC cards to negoti-
ate the links. No statistics are generated during this delay, and the status message
indicates that the test is in the preparation stage.
• EnableISAKMPLog on | off
Enables or disables the creation of a log file for IPSec Phase 1 and Phase 2 negoti-
ation processes. You access the log file (called trace-SA.xml) by analyzing test
results. You can open the test results files using Spirent Communications' report-
ing tools (Avalanche Analyzer or the URL Trace Tool) or any spreadsheet program
that is capable of reading comma-delimited files, such as Microsoft Excel. The
default is off.
• EnableISAKMPLogOnError on | off
Enables or disables the creation of a log file during IPSec Phase 1 and Phase 2
negotiation processes that contains only errors.
The default is off.
• EnableHostStats on | off
Enables or disables the creation of statistics, including IP, TCP, and IPSec, on a
host-by-host basis (that is, by client IP address). You can open the statistics file
(called hostStats.csv) using Spirent Communications' reporting tools (Avalanche
Analyzer or the URL Trace Tool) or any spreadsheet program that is capable of
reading comma-delimited files, such as Microsoft Excel. The default is off.
Note: You may see a degradation in performance because of the large number of
statistics being generated.
Chapter 4
Functions
This chapter contains all the function calls you can use in scripts to generate test files,
access the information in a test configuration array, upload the test to both the client and
the server, start the test on the server, start the test on the client, stop the server, get the test
results, and perform other useful functions.
In this chapter...
• Clustered Functions . . . . 182
• Query Functions . . . . 191
• Spirent TestCenter Functions . . . . 194
• Appliance Functions . . . . 197
• Standard Functions . . . . 200
• Interactive Testing Functions . . . . 212
Chapter 4: Functions
Clustered Functions
Clustered Functions
The following clustered functions are designed to be used in test scripts for one or more
appliances or Spirent TestCenter chassis.
• AbortClusteredTest
• AddUnitToCluster
• ClearEventLogs
• CreateCluster
• DeleteCluster
• GenerateClusteredTest
• GetClusteredTestResults
• IsClusteredTestRunning
• RegisterStatsCallback
• RemoveClusteredTest
• RemoveUnitFromCluster
• StartClusteredTest
• StopClusteredTest
• UnregisterStatsCallback
• UploadClusteredTest
• ValidateClusteredTest
• WaitForClusteredTestCompletion
Clustered Functions
General Terminology for Clustered Functions

Use one or more of the following parameters with clustered functions:
• cluster: A cluster consists of a group of appliances or Spirent TestCenter cards
functioning as either the client or server side of a test.
• clusterID: A clusterID is a unique identifier associated with a cluster. It is generated
by the API and returned to the user upon creation of a cluster.
• unitID: A unit identifier uniquely identifies a specific appliance or Spirent TestCenter
resource and is composed of the following: <unitIP>;<unitNumber>.
• unitIP: The IP address of the appliance or Spirent TestCenter card.
• unitNumber: Equivalent to the processor number on the appliance, which can be
either 0 or 1 for a 2500, and 0 for a 250.
AbortClusteredTest
Description Sends an abort command to all unit IDs within a cluster specified in the clusterID
parameter, which aborts the test immediately with no cleanup and no statistics generated.
Syntax SPI_AV::ClusterController::AbortClusteredTest <clusterID>
Parameters • <clusterID>
The unique ID of the cluster to receive the abort command
Return Value 1 - Abort command sent successfully
Comments Unlike StopTest, the cluster aborts the test immediately (does not ramp-down) with no
cleanup and does not generate results files for the test.
AddUnitToCluster
Description Allows you to add a unit (unitID) to an existing cluster.
Syntax SPI_AV::ClusterController::AddUnitToCluster <clusterID>
The unique identifier of the cluster to add
• <unitID>
The unique unit IP address and unit number of the cluster to add
Return Value 1 - Unit successfully added to the cluster
Comments None
Clustered Functions
ClearEventLogs
Description Clears the event logs for all the units in the specified cluster.
Syntax SPI_AV::ClusterController::ClearEventLogs <clusterID>
The unique identifier of the cluster from which all event logs are to be cleared
Return Value None
Comments The event log keeps track of various events as they occur during a test run. This data is
used to troubleshoot the system and is intended primarily for support engineers.
CreateCluster
Description Clears a new client or server cluster.
Syntax SPI_AV::ClusterController::CreateCluster <ipAddress>

<unitNumber>
Parameters • <clusterType>
Specify client to create a client-based cluster or server to create a server-based
cluster
• <clusterName>
Specify the name of the cluster to create
• <unitIdList>
Specify a standard Tcl list of unit IDs to incorporate into the cluster
Return Value Returns a clusterID, which is a unique identifier for the newly created cluster generated by
the API
Comments None
DeleteCluster
Description Deletes an existing cluster.
Syntax SPI_AV::ClusterController::DeleteCluster <clusterID>
Specify the cluster identification number of the cluster to delete
Clustered Functions
Return Value 1 - Unit successfully deleted from the cluster

0 - Problem encountered while deleting cluster
Comments None
GenerateClusteredTest
Description Generates the clustered test according to the information specified within the
configuration array and stores it locally in the directory specified in the testDirectory
parameter. Upon successfully generating a clustered test, a list is returned containing the
client cluster ID and server cluster ID.
Syntax SPI_AV::ClusterController::GenerateClusteredTest
<configArrayName> <testDirectory> <testId> <loadDivision>
Parameters • <configArrayName>
Name of the array containing the test configuration information
• <testDirectory>
Local directory where the newly created test is to be placed
• <testId>
Name to be given to the test being created
• <loadDivision>
Optional, defaults to "1"
Enable (1) or disable (0) Load Division on a per unit basis within the test
Return Value None
Comments Because the generated test is not associated with any specific appliance or Spirent
TestCenter hardware, you can run the same generated test on different appliances or cards.
You can run the GenerateTest portion of the test separately and each time the test starts
running. It does not need to generate the test XML files. This function enables you to build
a collection of re-usable tests.
GetClusteredTestResults
Description Transfers the most recent result files for the specified cluster test to the specified
localDirectory.
Syntax SPI_AV::ClusterController::GetClusteredTestResults <clusterID>

<testID> <localDirectory>
Clustered Functions
Specify the cluster identification number of the cluster to get results from
• <testID>
Specify the name of the test from which results are required
• <localDirectory>
Location on the local machine to store the results files
Return Value 1 - Results successfully transferred to the specified local directory
Comments None
IsClusteredTestRunning
Description Allows you to determine whether a specified cluster is currently running a test.
Syntax SPI_AV::ClusterController::IsClusteredTestRunning <ipAddress>

<unitNumber>
Parameters • <ipAddress>
IP address of the device to test
• <unitNumber>
Unit number on which the test is or is not running
Return Value 1 - The cluster is currently running a test

0 - No test is currently running on the cluster
Comments None
RegisterStatsCallback
Description Registers a statistics callback function and returns its callbackID. The callbackFunc
function will be called for each subsequent statistics message received from the cluster. If
specified, the statistics will be filtered according to the filters specified by filterList.
Syntax SPI_AV::ClusterController::RegisterStatsCallback <clusterID>

<callbackFunc> {filterList {}}
Specify the cluster identification number
• <callbackFunc>
Callback function to be called (see Comments on page 187).
Clustered Functions
• {filterList {}}
List of filters to be applied to the statistics indices prior to calling callbackFunc
(see Comments on page 187). For a complete list of filters you can use,
see Appendix A, “Statistics Message Indices.”
Return Value Returns the callback ID of the newly created callback.
Comments The returned callbackID should be passed as an argument to

UnregisterStatsCallback to unregister the callback when it is no longer required.
RemoveClusteredTest
Description Removes the specified test from an existing cluster.
Syntax SPI_AV::ClusterController::RemoveClusteredTest <clusterID>

<testID>
The cluster identification number of the client or server cluster from which to remove
the test
• <testID>
Unique ID (name) of the test to be removed
Return Value None
Comments None
RemoveUnitFromCluster
Description Removes the specified test from an existing cluster.
Syntax SPI_AV::ClusterController::RemoveUnitFromCluster <clusterID>

<unitID>
The cluster identification number of the cluster from which to remove the unit
• <unitID>
The unique unit IP address and unit number of the unit to remove from the cluster
Return Value None
Comments None
Clustered Functions
StartClusteredTest
Description Starts the specified cluster test.
Syntax SPI_AV::ClusterController::StartClusteredTest <clusterID>

<testID> <statsMode>
The cluster identification number of the cluster on which to start the test
• <testID>
Unique ID (name) of the test to run
• <statsMode>
Optional, defaults to “full”
Can be “full”, “summary”, or “quick”
Return Value 1 - Clustered test has started successfully
Comments None
StopClusteredTest
Description Sends a stop command to the specified cluster instructing it to stop the currently running
test, perform additional cleanup, and generate statistics.
Syntax SPI_AV::ClusterController::StopClusteredTest <clusterID>
The cluster identification number of the cluster running the test to stop
Return Value 1 - Clustered test has stopped successfully
Comments This function does not wait for the test to complete; therefore, you should call
WaitForClusteredTestCompletion before attempting to start another test on this
unit. Although stopped prematurely, results files for the test will be created and can be
retrieved by calling GetClusteredTestResults.
UnregisterStatsCallback
Description Unregisters a previously registered callback using the callbackID returned from
RegisterStatsCallback and clusterID
Syntax SPI_AV::ClusterController::UnregisterStatsCallback <clusterID>

<callbackID>
The cluster identification number of the cluster from which to unregister the callback
Clustered Functions
• <callbackID>
ID of the callback to be unregistered
Return Value 1 – Callback unregistered successfully

0 – Failed to unregister callback
Comments The callbackID is returned upon creation of the callback using the
RegisterStatsCallback function.
UploadClusteredTest
Description Uploads the test testId located within the testDirectory on the local machine to the
specified device. The unitNumber indicates which unit/processor this test will
subsequently be run on. testType (“client” or “server”) indicates whether to upload the
client side or server side of the test. Uploads a pre-generated clustered test to a specified
cluster (i.e. client or server cluster).
Syntax SPI_AV::ClusterController::UploadClusteredTest <clusterID>

<testDirectory> <testId>
The cluster identification number of the client or server cluster on which to upload
the test
• <testDirectory>
Local directory containing the test to be uploaded
• <testId>
Unique ID (name) of the test to be uploaded
Return Value None
Comments The test directory specified should be the same directory as the one passed to
GenerateClusteredTest.
ValidateClusteredTest
Description Validates the specified clustered test.
Syntax SPI_AV::ClusterController::ValidateClusteredTest
<clientClusterID> <serverClusterID> <testID> <userID>
<statsMode>
Parameters • <clientClusterID>
The cluster identification number of the client cluster on which to validate the test. If
you do not specify a client cluster ID, you must enter ““ in its place, as well as provide
the server cluster identification number.
Clustered Functions
• <serverClusterID>
The cluster identification number of the server cluster on which to validate the test. If
you do not specify a client cluster ID, you must enter ““ in its place, as well as provide
the client cluster identification number.
• <testID>
Unique ID (name) of the test to validate
• <userID>
Optional, provides the identification string to use to lock the specific resource (if you
do not want to specify a user ID, you must enter ““ in its place)
• <statsMode>
Optional, defaults to “full”
Return Value 1 – Test validated with no problems

0 – Test validated and encountered problem(s)
Comments Before validating a test, you must upload the test to the specified cluster using the
UploadClusteredTest function.
If both a client and server cluster ID are provided, then validation will occur in exactly the
same way as validation occurs in the Layer 4-7 Application (that is, one iteration of the
test with results). If only a server cluster ID is provided, then the test is validated at an
XML level and no results are returned.
If you do not specify the <clientClusterID> or <serverClusterID> parameter,
you must specify ““ in its place. For example, to only validate a server test, specify the
following:
SPI_AV::ClusterController::ValidateClusteredTest ““
myServerClusterID myTest full
WaitForClusteredTestCompletion
Description Blocks until the specified cluster completes any currently running test (that is, until the
units’ test stage reaches “Stopped”).
Syntax SPI_AV::ClusterController::WaitForClusteredTestCompletion
<clusterID>
The cluster identification number of the cluster to block
Return Value None
Comments If the cluster is already in the “Stopped” state, this function returns immediately.
Query Functions
Query Functions
You can use the following query functions to query and modify both the API and the test
configuration array for specific information.
• GetParameter
• GetProfileName
• GetProfileParameters
• GetProfileType
• GetValidProfileTypes
• SetParameter
GetParameter
Description Enables you to obtain one or more parameter values for a particular test configuration
array.
Syntax SPI_AV::GetParameter <test configuration array name>

<profileNameOrType> <parameter>
Parameters • <test configuration array name >

Name of the test configuration array containing values you want to retrieve
• <profileNameOrType>
Name of the profile or type from which to obtain the specified parameter value
• <parameter>
(Optional) The parameter from which you require a value. If you do not specify a
parameter, then the entire list of parameters and their associated values for the speci-
fied profile type are returned.
Return Value If the operation completed successfully, returns a standard Tcl list of parameters that
belong to the specified test configuration array for the specified profile and their
associated values, constructed as follows:
{<completeParam1> <value> <completeParam1> <value>}.
Otherwise, returns an error message or 0 if it encountered a problem.
Comments When specifying a profile name or parameter, you can use the '*' wildcard character. For
example, if you had two subnet profiles called 'subnet_1' and 'subnet_2', then using
'subnet_*' would include both subnet profiles.
GetProfileName
Description Returns a list of current profile names for the specified list of profile types.
Query Functions
Syntax SPI_AV::GetProfileName <test configuration array name>

<profileTypeList>

Name of the test configuration array containing values you want to retrieve
• <profileTypeList>
(Optional) A standard Tcl list (that is, space delimited) consisting of profile types from
which you want to acquire the profile names. If you do not specify a profile type, then
the entire list of profile names within the test configuration array are returned.
Return Value If the operation completed successfully, returns a standard Tcl list of profile names (for
example, Sample lp Sample up). Otherwise, returns an error message if it encountered a
problem.
Comments None
GetProfileParameters
Description Returns a list of valid profile parameters for the specified profile type.
Syntax SPI_AV::GetProfileParameter <profileType> <filter>
Parameters • <profileType>
Type of profile from which to obtain a parameter list (for example, WaInterface)
• <filter>
(Optional) A filter (that is, DDOS, FlatSub, etc.) to limit the returned parameter list. If
you do not specify a filter, then all permitted parameters are returned.
Return Value If the operation completed successfully, returns a standard Tcl list of parameter syntax. For
example, if WaInterface was specified as the Profile Type, and RouterSet as filter, then a
list of the following form would be returned:
WaInterface,<filename>,RouterSet,0,MacMasquerade,Mac0
WaInterface,<filename>,RouterSet,0,MacMasquerade,Mac1
WaInterface,<filename>,RouterSet,0,NetmaskBits
WaInterface,<filename>,RouterSet,0,VlanId
Otherwise, returns an error message if it encountered a problem.
Comments Certain parameters will contain 'N' which refers to an iterative index. Please refer to the
appropriate section within this document for further information.
GetProfileType
Description Returns a list of current profile types for the specified list of profile names.
Query Functions
Syntax SPI_AV::GetProfileType <test configuration array name>

<profileNameList>

Name of the test configuration array containing the profile type you want to retrieve
• <profileNameList>
(Optional) A standard Tcl list (that is, space delimited) consisting of Profile Names
from which you want to acquire the Profile Types. If you do not specify a profile name
list, then the entire list of profile types within the test configuration array are returned.
Return Value If the operation completed successfully, returns a standard Tcl list of profile types (for
example, WaTestProfiled WaLoadProfile ...). Otherwise, returns an error message if it
encountered a problem.
Comments None
GetValidProfileTypes
Description Returns a list of valid profile types from which you can retrieve information.
Syntax SPI_AV::GetValidProfileTypes
Parameters None
Return Value Returns a standard Tcl list of valid profile types (for example, WaTestProfile
WaLoadProfile ...)
Comments None
SetParameter
Description Enables you to modify a specific test configuration array parameter value.
Syntax SPI_AV::SetParameter <test configuration array name>

<profileNameOrType> <parameter> <value> <setMultiple>

Name of the test configuration array containing the value to modify
• <profileNameOrType>
Name of the profile or type from which to obtain the specified parameter value
• <parameter>
The parameter containing the value to modify
Spirent TestCenter Functions
• <value>
The new value for the parameter to modify.
• <setMultiple>
Enable (1) or disable (0) the simultaneous modification of multiple parameters when
your search configuration returns multiple results.
Return Value 0 – Encountered a problem

1 – Operation completed successfully
Comments When specifying a profile name or parameter, you can use the '*' wildcard character. For
example, if you had two subnet profiles called 'subnet_1' and 'subnet_2', then using
'subnet_*' would include both subnet profiles.
Returns an error message if setMultiple is disabled, but the specified search parameters
return multiple results.

Spirent TestCenter cards are segregated into a number of port groups, each containing two
to three individual ports, depending on the model. Once provisioned, these port groups are
reserved for your use and flagged as locked to other users. Because these cards function
like standard client/server appliances, you can use the standard function calls provided by
the API to interact and instantiate tests.
The following functions are designed for use with Spirent TestCenter hardware to
facilitate the provisioning (locking and configuration) process:
• CleanUp
• ProvisionPorts
To communicate with a locked port group, you must use the following syntax:
<TestCenter Chassis IP>:<Card Slot>,<Port Group>
For example, to issue a GetStatus command to a standard appliance, you would enter:
SPI_AV::GetStatus 192.168.0.1
However, to issue the same command to a Spirent TestCenter port group, you would enter:
SPI_AV::GetStatus 192.168.0.2:1,1
The GetStatus command has been issued against the first port group on the card (that
is, giving access to the first two ports on the card) in slot location 1 in chassis 192.168.0.2.
CleanUp
Description Removes user locks from all Spirent TestCenter ports provisioned with the
ProvisionPorts command.
Syntax SPI_AV::STC::CleanUp
Parameters None

Comments This function removes any and all links that your script has with all Spirent TestCenter
hardware, which essentially returns the chassis and ports to their initial state. You will
need to re-provision your ports.
ProvisionPorts
Description Locks and configures a series of Spirent TestCenter ports so that they can be used within
standard tests.
Syntax SPI_AV::STC::ProvisionPorts <provisionList>
Parameters • <provisionList>
User-created standard Tcl list where each list element must adhere to the following
syntax:
{portId portMac portMedia portDuplex portSpeed portAuto-
Negotiation}
• <portId>
The location of the Spirent TestCenter port in the following format:
<SpirentTestCenter Chassis IP>:<slot>,<port>
• <portMac>
Specifies the MAC address the interface has been assigned via provisioning using
the following syntax: XX-XX-XX-XX-XX-XX.
• <portMedia>
Specifies the media type of the card as either copper or fiber.
• <portDuplex>
Specifies the interface duplex mode, assigned during provisioning, as one of the
following: half, h, full, or f.
• <portSpeed>
Specifies the interface speed, in Mbps, assigned during provisioning, as one of the
following: 10, 100, 1000, or 10000.
• <portAuto-Negotiation>
Enables (force) or disables auto negotiation assigned during provisioning on the
current interface.
Note: Enabling auto negotiation on a given port takes precedence over any user-
specified speed or duplex setting.
Return Value Error with message – Encountered a specific problem when attempting to provision the
requested resources.
0 – Encountered a problem
Comments All provisionList parameters are mandatory and must be included.
Example Example of a short provisioning script:

# Assume that we have already 'package required' the SPI_AV API and
# it has been correctly licensed before this point…
#
# Build a simple provisioning list to provision four ports on a single
Spirent TestCenter card located in slot 1, in chassis 192.168.0.2
#
# The four ports encompass two port groups - group 1 (ports 1 & 2) &
# group 2 (ports 3 & 4)
#
"00-00-00-00-00-a1""Copper" "Full" "100" "Disable"]
lappend stcProvisionList [list "192.168.0.2:1,2"\
# Attempt to provision the required port groups

if {[SPI_AV::STC::ProvisionPorts $stcProvisionList]} {
puts "All ports provisioned properly"
}
# Check the status of the dispatcher processes on both newly

# provisioned port groups by issuing a GetStatus command to each.
puts "\nDispatcher at 192.168.0.2:1,1 [SPI_AV::GetStatus \

192.168.0.2:1,1]"
puts "\n\nDispatcher at 192.168.0.2:1,2 [SPI_AV::GetStatus \
192.168.0.2:2,1]"
Appliance Functions
# Release all cards

SPI_AV::STC::CleanUp
# Test complete
puts "Test Complete"
Appliance Functions
Appliances are segregated into a number of port groups or “units.” You can reserve these
units for your use, in which case they are flagged as locked to other users.
The following functions are designed for use with appliance hardware to facilitate the
reservation process:
• ReserveAppUnits
• ReleaseAppUnits
Note: The term “unit” is used throughout this section to denote the appliance port group
or CPU number, or 10GbE virtual port number.
ReserveAppUnits
Description Reserves a series of appliance units for your use when running a test.
Syntax SPI_AV::Appliance::ReserveAppUnits <unitList> <ip10GbeList>
Parameters • <unitList>
Client and server unit list adhering to the following syntax:
<ipAddress>:<unitNo> <ipAddress>:<unitNo> ...
• <ipAddress>
IP address of the appliance
• <unitNo>
Appliance unit/port group number, or 10GbE virtual port number (zero-relative)
• <ip10GbeList>
This parameter is used only for the 2900 appliance, 10GbE port group. (Omit this
parameter, if you are using the other port groups.)
If you plan to run your test using the10GbE port group, you must specify the corre-
sponding list of 2900 appliance IP address(es) that you specified in the ipAddress
parameter of unitList, using the following format:
<ipAddress> <ipAddress> ...
Appliance Functions
Note: On the 2900 appliance, the 10GbE port group contains 0-7 virtual ports, and
you can specify these ports individually when you configure a test. However, the
system reserves/releases all of these virtual ports together as a whole.
Return Value If successful, returns a reservation status list containing each unit’s status in the following
format:
<ipAddress unitNo user reserveState> <ipAddress unitNo user
reserveState> ...
• ipAddress
• unitNo
• user
User ID in the form of <username>@<hostname>
• reserveState
0 – Not previously reserved by the same user
1 – Previously reserved by the same user
If unsuccessful, returns "".
Comments At the end of the test run, all your reserved appliance units are automatically released,
unless they were found to be already reserved at the start of the test (for example, via GUI
reservation).
ReleaseAppUnits
Description Removes reservations from appliance units that you reserved with the
ReserveAppUnits command. Normally, you should provide the reservation status list
that was returned from the ReserveAppUnits command to remove all reservations
obtained through ReserveAppUnits. However, you can modify this list to remove
specific reservations, as required.
Syntax SPI_AV::Appliance::ReleaseAppUnits <previousReserveStatus>

<ip10GbeList>
Parameters • <previousReserveStatus>
The reservation status list that was returned from the ReserveAppUnits command
in the following format:
<ipAddress unitNo user reserveState> <ipAddress unitNo user
reserveState> ...
• ipAddress
Appliance Functions
• unitNo
• user
User ID in the form of <username>@<hostname>
• reserveState
0 – Not previously reserved by the same user
1 – Previously reserved by the same user
• <ip10GbeList>
This parameter is used only for the 2900 appliance, 10GbE port group. (Omit this
parameter, if you are using the other port groups.)
If you plan to run your test using the10GbE port group, you must specify the corre-
sponding list of 2900 appliance IP address(es) that you specified in the ipAddress
parameter of previousReserveStatus, using the following format:
<ipAddress> <ipAddress> ...
Note: On the 2900 appliance, the 10GbE port group contains 0-7 virtual ports, and
you can specify these ports individually when you configure a test. However, the
system reserves/releases all of these virtual ports together as a whole.

Comments This function releases your reserved appliance units, as specified in the
previousReserveStatus parameter, unless they were found to be already reserved at
the start of the test (for example, via GUI reservation).
Standard Functions
Standard Functions
The following functions are designed to be used in any test script, regardless of whether it
is a test for a cluster of appliances or Spirent TestCenter cards or a test for a single unit
appliance or chassis:
• AddLicense
• AdjustLoad
• CleanUp
• DownloadCookies
• Dump
• GetAdminConfig
• GetEventLog
• GetHostList
• GetInterfaceList
• GetLastError
• GetNumInterfaces
• GetRealTimeStats
• GetStatus
• InitializeAPI
• Reboot
• StartSNMPPolling
• StopSNMPPolling
Standard Functions
AddLicense
Description Allows you to use the API with the equipment specified within the supplied license.
Alternatively, if a license file is not available, then this function allows you to use the API
in demo mode. When running tests in demo mode, the API attempts to stop the test after
approximately 100 seconds. The test capability (that is, maximum load, etc.) is also
drastically reduced in demo mode. The back end handles the other limitations.
Syntax SPI_AV::AddLicense <license file path> | "-Demo" | -STC

<ChassisIp1> <ChassisIp2>...<ChassisIpN>
Parameters • <license file path>

Specifies the file path to a license file (for example, SPI_AV::AddLicense "/home/user/
license.xml")
• -Demo
Runs the API in demo mode
• -STC <ChassisIp> <ChassisIp2>...<ChassisIpN>
Licenses the specified Spirent TestCenter chassis IP addresses for testing
Return Value 1 - License file added successfully, or demo mode entered successfully
0 - Problem encountered while validating license
Comments Always add this function directly after the InitializeAPI function. Because multiple
licenses are permitted within a test, you can call this function multiple times. However,
when running tests in demo mode, any previously added licenses or any subsequent added
licenses are disabled and ignored, respectively. The API is either licensed to use specific
hardware or placed in demo mode.
AdjustLoad
Description Adjusts the selected load of an actively running test by directly setting the load to a
desired value, or by increasing or decreasing the existing load level by a desired amount.
Syntax SPI_AV::AdjustLoad <platformId> <unitNumber> <adjustment>

[<userId> [<loadIndex>]]
Parameters • <platformId>
• <ipAddress>
For an appliance, enter the IP address of the appliance.
• <ipAddress>:<slotNumber>,<portGroupNumber>
For Spirent TestCenter, enter the IP address of the chassis, test module number
(slot number), and port group number.
• <unitNumber>
Standard Functions
The number of the unit on which the port belongs

• Enter an integer between 0 and 3 for 2500 and 2700 appliances
• Enter an integer between 0 and 7 for 2900 appliances
• Enter 0 for all types of Spirent TestCenter cards, except the CPU-5001A (High
Performance CPU Module)
• Enter an integer between 0 and 3 for the CPU-5001A (High Performance CPU
Module)
• <adjustment>
Specify the load adjustment to be either an absolute value to attain (for example, 100)
or the amount by which to adjust the load (for example, +100 or -100). Use the + or -
operators to increase/decrease the load by the specified integer value. Omit the opera-
tor to set the load to the specified integer value.
• <userId>
Optional, defaults to ""
• <username>@<hostname>
In the default case, the username and hostname environment variables,
defined where the script is running, are used to form the userId.
• <loadIndex>
Optional, defaults to 0
The index of the load profile requiring modification. The default (0) represents the
“Summary” (total) for the specified unit. So, for a global load profile, you should keep
the default setting. For a user-based load profile, set this index to start with 1.
Note: A load index of 0 is not valid for a user-based load profile, and is ignored
unless the load profile is a global load profile.
The load index for a user-based load profile is determined for each unit/port group
separately. The following example shows the user profile’s configArray entries for
a 2500 appliance:
WaUserProfile,ConnsPerSec_up1_0,LoadProfile {ConnsPerSec_lp1}\
For unit 0, load profiles ConnsPerSec_lp1 and ConnsPerSec_lp2 should have

load index values of 1 and 2, respectively. For unit 1, load profiles
ConnsPerSec_lp3 and ConnsPerSec_lp4 should also have load index values of
1 and 2, respectively. The load index value, combined with the unit number, specifies
a specific user-based load profile.
Return Value 1 - Load adjusted successfully

0 - Problem encountered while attempting to adjust the load
Standard Functions
Comments None
CleanUp
Description Allows the API to perform cleanup operations required to exit gracefully.
Syntax SPI_AV::CleanUp
Parameters None
Return Value None
Comments Every script that uses the API should call CleanUp when the API is no longer required.
DownloadCookies
Description Downloads all cookies created during a test.
Syntax SPI_AV::DownloadCookies <ipAddress> <unitNumber> <testType>

<localDirectory>
IP address of the device or Spirent TestCenter port group ID
• <unitNumber>
The number of the unit from which to download cookies
• <testType>
Specifies whether this test is a “client” or “server” test
• <testId>
The unique ID (or name) of the test for which you want to get cookies
Location on the local machine from which to download the cookies
Return Value None
Comments None
Dump
Description Creates a debug file named “<test name>_apidump.dbg” within the directory in which the
script exists. You can use this debug file to help you determine why a fatal error occurred
during the test.
Standard Functions
Syntax SPI_AV::Dump
Parameters None
Return Value <testname>_apidump.dbg
Comments We recommend that you call this function from within a test script.
GetAdminConfig
Description Returns information regarding the current admin configuration of the specified device.
Syntax SPI_AV::GetAdminConfig <ipAddress> [<userId>] [<unitNumber>]
• <userId>
• <unitNumber>
Module)
Return Value Returns a list of index/value pairs representing the current admin configuration.
Comments None
Example Return adminNetworkConfig,defaultDomainName:

(index: value) adminNetworkConfig,defaultGateway: 10.7.18.140
adminNetworkConfig,dnsServerList:
adminNetworkConfig,dnsServerList,0,: 10.7.18.35
adminNetworkConfig,dnsServerList,1,: 0.0.0.0
adminNetworkConfig,hostname: localhost
adminNetworkConfig,ipAddress: 10.7.18.100
Standard Functions
adminNetworkConfig,macAddress: 00:10:f3:01:d5:ad
adminNetworkConfig,subnetMask: 255.255.255.0
adminNetworkConfig,useDhcp: false
dispatcherVersion: 1.0
errorMessage:
hasSslAccelerator: false
interfaceList:
interfaceList,0,description: type:FastEth,vendor:Intel,device:82559
interfaceList,0,interfaceId: 0
interfaceList,1,description: type:FastEth, vendor:Intel,device:82559
modelNumber: 220
numberOfUnits: 1
osVersion: 62108
returnCode: 0
returnFiles:
serialNumber: 0010f301d5ad
softwareVersion: 6.2.0.30909 May 27 2004 14:09:42
GetEventLog
Description Returns a list of index/value pairs that represent the current contents of the event log on
the specified device.
Syntax SPI_AV::GetEventLog <ipAddress> [<userId>] [<unitNumber>]
IP address of the device or Spirent TestCenter port group ID from which to remove the
test
• <userId>
• <unitNumber>
Standard Functions
Module)
Return Value Returns a list of index/value pairs representing the event log.
Comments Only the last 50 messages are guaranteed to be available, although up to 100 may be
returned.
Partial Example ... ... ... ... ... ... ...

Return (index: eventLog,6,: 10.7.18.100 <7303195>: WebAvalanche Version: 6.2.0.30909
value): May 27 2004 14:09:42
eventLog,7,: 10.7.18.100 <7303195>: Command Line: wawr -w -i 0 -c 0 -a
0 -p 406 -m full -d /swat/tests/unit0/SampleTest
-s 50000
eventLog,8,: 10.7.18.100 <7303195>: Running on Processor: 0
eventLog,9,: 10.7.18.100 <7303195>: Creating EventProcessor
eventLog,10,: 10.7.18.100 <7303195>: Created EventProcessor
eventLog,11,: 10.7.18.100 <7303195>: Nitrox 1 driver ver 2.2
eventLog,12,: 10.7.18.100 <7303195>: Cavium version 1.0?
eventLog,13,: 10.7.18.100 <7303195>: Cavium device not found
... ... ... ... ... ... ...
eventLog,25,: 10.7.18.100 <7303195>: Cluster sync received, continuing
test.
eventLog,26,: 10.7.18.100 <7303195>: Test Test Name starting
eventLog,27,: 10.7.18.100 <7303195>: Load Generation Ramp Up Started
GetHostList
Description Returns information regarding the host list of the specified device.
Syntax SPI_AV::GetHostList <ipAddress> [<userId>] [<unitNumber>]
• <userId>
In the default case, the username and hostname environment variables, defined
where the script is running, are used to form the userId.
Standard Functions
• <unitNumber>
Module)
Return Value Returns a list of index/value pairs representing the host list.
Comments None
GetInterfaceList
Description Returns information regarding the interfaces on the specified device.
Syntax SPI_AV::GetInterfaceList <ipAddress> [<userId>] [<unitNumber>]
• <userId>
• <unitNumber>
Module)
Return Value Returns a list of index/value pairs representing the interface list.
Comments None
Standard Functions
Example Return interfaceList,0,description: type:FastEth,vendor:Intel,device:82559

(index: value): interfaceList,0,interfaceId: 0
interfaceList,1,description: type:FastEth,vendor:Intel,device:82559
GetLastError
Description Returns the last error encountered by the dispatcher process running on the specified
appliance.
Syntax SPI_AV::GetLastError <ipAddress>
Return Value Returns the last error or exception encountered by the dispatcher process.
Comments To remove all previously stored errors, call SPI_AV::ClearEventLog.
GetNumInterfaces
Description Returns the number of interfaces that are present on the target device.
Syntax SPI_AV::GetNumInterfaces <ipAddress>
Return Value None
Comments None
GetRealTimeStats
Description Returns the real-time statistics in their raw format (as they are received directly from the
unit).
Syntax SPI_AV::GetRealTimeStats <ipAddress> <unitNumber> [<userId>]
Standard Functions
• <unitNumber>
Unit number on which the test is running
• <userId>
Return Value Returns a list of index/value pairs representing the current statistics.
Comments None
Partial Example stats,stats,tcp,attemptedConnRate: 1

Return (index: stats,stats,tcp,attemptedConns: 10
value):
stats,stats,tcp,connSampleCountDelta: 0
stats,stats,tcp,currentEstablishedConns: 0
stats,stats,tcp,currentEstimatedServerProcTime: 0
stats,stats,tcp,currentTimeToFirstByte: 0
stats,stats,tcp,currentTimeToSynAck: 0
stats,stats,tcp,establishedConnRate: 0
stats,stats,tcp,maxEstimatedServerProcTime: 0
stats,stats,tcp,maxTimeToFirstByte: 0
stats,stats,tcp,maxTimeToSynAck: 0
stats,stats,tcp,minEstimatedServerProcTime: 0
stats,stats,tcp,minTimeToFirstByte: 0
stats,stats,tcp,minTimeToSynAck: 0
GetStatus
Description Returns information detailing the status of each unit on the specified device.
Syntax SPI_AV::GetStatus <ipAddress> [<userId>] [<unitNumber>]
• <userId>
Standard Functions
• <unitNumber>
Module)
Return Value Returns a list of index/value pairs representing the current status.
Comments None
Example Return unitStatusList,0,exitCode: 0

(index: value): unitStatusList,0,exitStatus: Finished
unitStatusList,0,testStage: Stopped
unitStatusList,0,unitNumber: 0
InitializeAPI
Description Must be called at the start of every test script to initialize the API.
Syntax SPI_AV::InitializeAPI
Parameters None
Return Value 1 - API successfully initialized

0 - Problem encountered
Comments None
Reboot
Description Causes the specified device to restart.
Syntax SPI_AV::Reboot <ipAddress> [<userId>] [<unitNumber>]
The IP address of the device or Spirent TestCenter port group ID
• <userId>
Standard Functions
• <unitNumber>
Module)
Return Value None
Comments None
Interactive Testing Functions

Use interactive testing functions when testing against a single appliance or Spirent
TestCenter card on the client and/or server side. These functions provide highly versatile
functionality, from creating, uploading, and starting a test against a single appliance or
card to querying the current test stage and retrieving results.
The following functions are described in this section:
• AbortTest
• ClearEventLog
• DebugLogFile
• GenerateTest
• GetTestResults
• GetTestStage
• IsTestRunning
• RegisterStatsCallback
• RemoveTest
• StartSNMPPolling
• StopSNMPPolling
• StartTest
• StopTest
• UnregisterStatsCallback
• UploadTest
• ValidateTest
• Version
• WaitForTestCompletion
AbortTest
Description Sends an abort command to the specified unit, which aborts the test immediately with no
cleanup and no statistics generated.
Syntax SPI_AV::AbortTest <ipAddress> <unitNumber> [<userId>]
• <unitNumber>
• <userId>
Return Value None
Comments Unlike StopTest, the unit aborts the test immediately (does not ramp-down) with no
cleanup and does not generate results files for the test. For example, you may want to
abort a test immediately if there are many outstanding open connections and you are not
interested in statistics, because a clean stop will take too long.
ClearEventLog
Description Clears the event log for the specified device.
Syntax SPI_AV::ClearEventLog <ipAddress> [<userId>] [<unitNumber>]
• <userId>
• <unitNumber>

Module)
Return Value None
Comments The event log keeps track of various events as they occur during a test run. This data is
used to troubleshoot the system and is intended primarily for support engineers.
DebugLogFile
Description Enables or disables the creation of a debug log file.
Syntax SPI_AV::DebugLogFile on | off
Parameters • on | off
Enable (on) or disable (off) the creation of a debug log file after a test run. Defaults to
“off.”
Return Value 1 - Successfully enabled the creation of a log file

0 - Problem encountered while attempting to create a debug log file
Comments The SPI_AV::Dump function operates independently of the SPI_AV::DebugLogFile

command. However, one of the things that the Dump function attempts to include is the
debug log file. Therefore, if you want to create an API dump file (.dbg), we recommend
that you re-run the test with the debug log file enabled so that it is included within the .dbg
file. If you use the SPI_AV::Dump function when SPI_AV::DebugLogFile is set to “off,”
then the .dbg file will not contain the debug log file.
GenerateTest
Description Generates the test according to the information specified within the configuration array
and stores it locally in the directory specified in the testDirectory parameter.
Syntax SPI_AV::GenerateTest <configArrayName> <testDirectory> <testId>

<numClientInterfaces> <numServerInterfaces>
Parameters • <configArrayName>
Name of the array containing the test configuration information
• <testDirectory>
Local directory where the newly created test is to be placed
• <testId>
Name to be given to the test being created
• <numClientInterfaces>
Number of interfaces to cater for on the client side
• <numServerInterfaces>
Number of interfaces to cater for on the server side
Return Value None
Comments Because the generated test is not associated with any specific appliance or Spirent
TestCenter hardware, you can run the same generated test on different appliances or cards.
You can run the GenerateTest portion of the test separately and each time the test starts
running. It does not need to generate the test XML files. This function enables you to build
a collection of re-usable tests.
GetTestResults
Description Transfers the most recent result files for the specified unit/test to the specified
localDirectory.
Syntax SPI_AV::GetTestResults <ipAddress> <unitNumber>

<testType><testIde> <localDirectory>
• <unitNumber>
Unit number to get the results from
• <testType>
Specifies whether the test is a “client” or “server” test.
• <testId>
Unique ID (name) of the test to get the results for
Location on the local machine to store the results files
Return Value None
Comments None
GetTestStage
Description Returns the test stage (that is, “ReadyToStart”, “PrepStarted”, “PrepComplete”,
“RampingUp”, “SteadyState”, “RampingDown”, “Stopped”) of the specified unit.
Syntax SPI_AV::GetTestStage <ipAddress> <unitNumber>
• <unitNumber>
Return Value Test stage of the specified unit.
Comments Exception if you encounter any problems.
IsTestRunning
Description Determines whether a test is currently running on the specified device.
Syntax SPI_AV::IsTestRunning <ipAddress> <unitNumber>
IP address of the device to test or Spirent TestCenter port group ID
• <unitNumber>
Return Value 1 – A test is currently running on the specified device.

0 – No test is currently running on the specified device.
Comments None
RegisterStatsCallback
Description Registers a statistics callback function and returns its callbackID. The callbackFunc
function will be called for each subsequent statistics message received from the unit. If
specified, the statistics will be filtered according to the filters specified by filterList.
Syntax SPI_AV::RegisterStatsCallback <ipAddress> <unitNumber>

<callbackFunc> <{filterLIst {}}>
IP address of the device or Spirent TestCenter ID of the port group
• <unitNumber>
Unit number to register the callback for
• <callbackFunc>
Callback function to be called (see Comments).
• <{filterList {}}>
List of filters to be applied to the statistics indices prior to calling callbackFunc
(see Comments). For a complete list of filters you can use, see Appendix A.
Return Value Returns the callback ID of the newly created callback.
Comments The returned callbackID should be passed as an argument to

UnregisterStatsCallback to unregister the callback when it is no longer required.
• callbackFunc
The value specified for callbackFunc should be the name of a proc with the
following prototype:
proc MyCallbackName {ipAddress unitNumber callbackData} {
... ... ...
}
As the same callback may be registered with more than one unit, the combination of
ipAddress and unitNumber identifies the unit that caused the callback to be
invoked. callbackData contains a list of index-value pairs that can easily be
converted to an array with the array set command. The indices present within
callbackData are dependent on how the statistics were filtered (see filter-
List).
• filterList
This parameter is optional and, if specified, determines what data is passed to the
callback function when it is invoked. Each item within the list represents a glob-style
pattern and only indices that match one (or more) of the filter patterns are included in
the callbackData list. For a complete list of filters you can use, see Appendix A.
Example set filterList [list “time*” “pop3”]

For a client test running, the above filter list causes the following indices to be present in
the callbackData:
timeElapsed
timeRemaining
pop3,abortedSessionsPerSec
pop3,activeSessions
pop3,attemptedSessionsPerSec
pop3,successfulSessionsPerSec
pop3,unsuccessfulSessionsPerSec
Note: Each pattern in the filterList has * appended to it internally prior to matching
which allows retrieval of all statistics within a “group” by including the group name in the
filterList (as for “pop3” in the previous example).
If the filterList parameter is omitted, then no filtering of the statistics occurs and the
callback function is passed the complete statistics message.
RemoveTest
Description Removes the specified test from the unit.
Syntax SPI_AV::RemoveTest <ipAddress> <unitNumber> <testType> <testId>
IP address of the device or Spirent TestCenter port group ID from which to remove the
test
• <unitNumber>
ID of the unit from which this test is to be removed
• <testType>
Specifies whether the test to remove is a “client” or “server” test
• <testId>
Unique ID (name) of the test to be removed
Return Value None
Comments None
StartSNMPPolling
Description Starts the SNMP Monitoring and returns the port to communicate with the SNMPpoller.
Syntax SPI_AV::StartSNMPPolling <testID> <testDirectory>

<GUI_install_directory>
Parameters • <testId>
• <testDirectory>
Local directory where the Tcl test and configuration files are located
• <GUI_install_directory>
Name of the Layer 4-7 Application’s directory in which the lib folder (with java .jar
files) is located
Return Value Returns the port number used to communicate with the SNMP poller. You use this number
to stop the poller.
Comments Refer to the Layer 4-7 Application’s online Help for more about SNMP Monitoring.
StopSNMPPolling
Description Stops the SNMP Monitoring on the specified port.
Syntax SPI_AV::StopSNMPPolling <port>
Parameters • <port>
Name of the port returned by the StartSNMPPolling function
Return Value None
Comments Refer to the Layer 4-7 Application’s online Help for more about SNMP Monitoring.
StartTest
Description Starts a specified test.
Syntax SPI_AV::StartTest <ipAddress> <unitNumber> <testType> <testId>

<statsMode>
IP address of the device or Spirent TestCenter port group ID on which to start the test
• <unitNumber>
Unit number on which the test is to be run
• <testType>
Specifies whether the test is a “client” or “server” test
• <testId>
• <statsMode>
Optional, defaults to "full"
Return Value None
Comments None
StopTest
Description Sends a stop command to the specified unit instructing it to stop the currently running test,
perform additional cleanup, and generate statistics.
Syntax SPI_AV::StopTest <ipAddress> <unitNumber> [<userId>]
• <unitNumber>
• <userId>
Return Value None
Comments This function does not wait for the test to complete; therefore, you should call
WaitForTestCompletion before attempting to start another test on this unit. Although
stopped prematurely, results files for the test will be created and can be retrieved by
calling GetTestResults.
UnregisterStatsCallback
Description Unregisters a previously registered callback using the callbackID returned from
RegisterStatsCallback.
Syntax SPI_AV::UnregisterStatsCallback <ipPAddress> <unitNumber>

<callbackID>
Parameters • <ipPAddress>
• <unitNumber>
Unit number for which to unregister the callback
• <callbackID>
ID of the callback to be unregistered
Return Value 1 – Callback unregistered successfully

0 – Failed to unregister callback
Comments None
UploadTest
Description Uploads the test testId located within the testDirectory on the local machine to the
specified device. The unitNumber indicates which unit/processor this test will
subsequently be run on. testType (“client” or “server”) indicates whether to upload the
client side or server side of the test.
Syntax SPI_AV::UploadTest <ipAddress> <unitNumber> <testType>

<testDirectory> <testId>
• <unitNumber>
Unit number that this test will be uploaded for
• <testType>
Indicates whether to upload the client portion or server portion of the test (“client” or
“server”)
• <testDirectory>
Local directory containing the test to be uploaded
• <testId>
Unique ID (name) of the test to be uploaded
Return Value None
Comments None
ValidateTest
Description Validates a specified test.
Syntax SPI_AV::ValidateTest <ipAddress> <unitNumber> <testType>

<testId> <statsMode>
IP address of the device on which to start the test or Spirent TestCenter port group ID
• <unitNumber>
Unit number on which the test is to be run
• <testType>
Specifies whether to run a “client” or “server” test
• <testId>
• <statsMode>
Optional, defaults to "full"
Return Value 1 – Test validated with no problems

0 – Test validated and encountered problem(s)
Comments Before validating a test, you must upload the test to all necessary units using the
UploadTest function.
Version
Description Provides the current version and build of the Scripting API.
Syntax SPI_AV::Version
Parameters None
Return Value Returns the current Tcl API version, for example, “Layer 4-7 TclAPI 2.10 Build 34567”
Comments None
WaitForTestCompletion
Description Blocks until the specified unit completes any currently running test (i.e. until the units’
test stage reaches “Stopped”).
Syntax SPI_AV::WaitForTestCompletion <ipAddress> <unitNumber>
• <unitNumber>
Return Value None
Comments If the unit is already in the “Stopped” state, this function returns immediately.
Appendix A
Statistics Message Indices
In this appendix...
• Client Statistics Message Indices . . . . 224
• Filters to Use for Client Statistics . . . . 225
• Server Statistics Message Indices . . . . 249
• Filters to Use for Server Statistics . . . . 250
Scripting API for Layer 4-7 Application Reference Manual | 223

Appendix A: Statistics Message Indices
Client Statistics Message Indices
Client Statistics Message Indices

The Client statistics message indices are different sets of filters you can use to determine
what data gets passed back to the callback function when it is invoked.
How to Use Them

The RegisterStatsCallBack function includes a filter list parameter. Each item within the
list represents a glob-style pattern and only indices that match one (or more) of the filter
patterns are included in the callbackData list.
The following example uses the set command to specify which data items you want to see.
set filterList [list “time*” “pop3”]

For a client test running, the above filter list will cause the following indices to be present
in the callbackData:
timeElapsed
timeRemaining
pop3,activeSessions
pop3,attemptedSessionsPerSec
pop3,successfulSessionsPerSec
pop3,unsuccessfulSessionsPerSec
If the filterList parameter is omitted, then no filtering of the statistics will occur and
the callback function will be passed the complete statistics message.
224 | Scripting API for Layer 4-7 Application Reference Manual

Filters to Use for Client Statistics

This section contains the complete list of message indices you can use when you create
filters for callback functions. It also provides descriptions of these protocols:
• TCP Capture-Replay
• UDP Capture-Replay
• DDOS
• DNS
• Driver
• FTP
• HTTP
• Load Specification
• Memory
• Miscellaneous
• POP3
• PPP
• PPPoE
• Simulated Users
• SMTP
• Streaming
• TCP
• TCPState
• Telnet
• URL
• SIP
• IPSEC
• MM4
These statistics are updated at a preconfigured sampling interval. You can set the time
interval with the RunTimeStatistics parameter.

TCP Capture-Replay
The Client Statistics TCP Capture-Replay message indices display a summary of Capture-
Replay TCP session activity, including sessions generated per second and active sessions.
These statistics show the network and/or device under test behavior when responding to
Capture-Replay TCP sessions generated by the client.
• capRepTcp,abortedConnsPerSec
The number of aborted Capture-Replay TCP sessions per second generated from the
client.
• capRepTcp,activeConns
The number of active Capture-Replay TCP sessions.
• capRepTcp,attemptedConnsPerSec
The number of attempted Capture-Replay TCP sessions per second generated from the
client.
• capRepTcp,successfulConnsPerSec
The number of successful Capture-Replay TCP sessions per second generated from the
client.
• capRepTcp,unsuccessfulConnsPerSec
The number of unsuccessful Capture-Replay TCP sessions per second generated from
the client.
UDP Capture-Replay
The Client Statistics UDP Capture-Replay message indices display a summary of
Capture-Replay UDP session activity, including sessions generated per second and active
sessions. These statistics show the network and/or device under test behavior when
responding to Capture-Replay UDP sessions generated by the client.
• capRepUdp,activeConns
The number of active Capture-Replay UDP sessions.
• capRepUdp,attemptedConnsPerSec
The number of attempted Capture-Replay UDP sessions per second generated from the
client.
• capRepUdp,successfulConnsPerSec
The number of successful Capture-Replay UDP sessions per second generated from
the client.
• capRepUdp,unsuccessfulConnsPerSec
The number of unsuccessful Capture-Replay UDP sessions per second generated from
the client.

DDOS
The Client Statistics DDOS message indices display statistics on DDoS traffic being
generated by the client, based on DDoS attack configurations. These statistics show the
network and/or device under test behavior when responding to DDoS attacks generated by
the client.
• ddos,desiredPacketsPerSec
The desired (configured) DDoS traffic in packets sent per second
• ddos,desiredTrafficPerSec
The desired (configured) DDoS traffic in kilobytes of data sent per second
• ddos,outgoingTrafficPerSec
The outgoing (realized) DDoS traffic in kilobytes of data sent per second
• ddos,sendPacketsPerSec
The outgoing (realized/actual) DDoS traffic in packets sent per second.
DNS
The Client Statistics DNS message indices display a summary of DNS activity, including
DNS queries generated per second and active DNS queries. These statistics show the
network and/or device under test behavior when responding to a number of DNS queries
generated by the client. DNS entries in the URL list that you create simulate a DNS client
sending different types of DNS name resolution requests to a DNS server.
• dns,activeQueries
The number of active DNS queries.
• dns,attemptedQueriesPerSec
The number of attempted DNS queries per second generated from the client. Query
types supported include the following: Address (A), Mail Exchange (MX), Name
Server (NS), Canonical Name (CNAME), Start of Authority (SOA), Pointer (PTR).
• dns,successfulQueriesPerSec
The number of successful DNS queries per second generated from the client. This total
includes all query types.
• dns,unsuccessfulQueriesPerSec
The number of unsuccessful DNS queries per second generated from the client. This
total includes all query types above. Some potential reasons why the query could fail
include the following:
• Record does not exist in the server’s zone file.
• Server is overloaded, and is rejecting additional query requests.

Driver
The Client Statistics Driver message indices display bandwidth utilization, both incoming
and outgoing, showing the bandwidth being used by the client and the network and/or
device under test. Other relevant metrics include packet traffic per second.
• driver,rxBandwidth
The incoming bandwidth traffic (sent to the client by the device under test).
• driver,txBandwidth
The outgoing bandwidth traffic (sent by the client to the device under test).
• driver,rxPacketRate
The incoming number of packets per second (sent to the client by the device
under test).
• driver,txPacketRate
The outgoing number of packets per second (sent by the client to the device
under test).
Note: To get the equivalent of driver,maxRxBandwidth and driver,maxTxBandwidth

for the Client side, simply maintain the highest driver,rxBandwidth and driver,txBand-
width value respectively.
FTP
The Client Statistics FTP message indices display a summary of FTP activity, including
data transfer rate, FTP sessions generated per second, and active FTP sessions. These
statistics show the network and/or device under test behavior when responding to a
number of FTP sessions generated by the client. They answer these important questions
about the network or device under test:
• How many concurrent FTP sessions can be supported?
• How many FTP sessions per second can be sent?
• How much data per second can be sent?
• ftp,attemptedSessionsPerSec
The number of attempted FTP sessions per second generated from the client. Transfer
of one file per session is supported. Therefore, the number of sessions/second is equal
to the number of file transfers/second.
• ftp,successfulSessionsPerSec
The number of successful FTP sessions per second generated from the client. Transfer
of one file per session is supported. Therefore, the number of sessions/second is equal
to the number of file transfers/second.

• ftp,unsuccessfulSessionsPerSec
The number of unsuccessful FTP sessions per second generated from the client. Trans-
fer of one file per session is supported. Therefore, the number of sessions/second is
equal to the number of file transfers/second.
• ftp,dataTransferRate
The amount of data, in kbytes per second, sent to the client by the FTP infrastructure.
• ftp,fileTransferRate
The number of files transferred per second.
HTTP
The Client Statistics HTTP message indices display the HTTP transaction load being
generated by the client and Quality of Service metrics, such as response time, that indicate
how the device under test is responding to the load generated.
• http,abortedTxns
The number of aborted transactions. This value totals the cumulative number of
Session aborted transactions, but does not include server resets that cause an early
termination of a connection.
• http,abortedTxnsPerSec
The number of aborted HTTP transactions per second. The HTTP protocol version
used is the one that you selected when you configured the client profile for the test.
• http,attemptedTxns
The total number of GETs, POSTs, and HEADs issued by all Sessions during a test.
Keep in mind that this may have nothing to do with the number of TCP connections
attempted.
• http,attemptedTxnsPerSec
The number of attempted HTTP transactions per second. The HTTP protocol version
used is the one that you selected when you configured the client profile for the test.
• http,successfulTxns
The total number of transactions that were completely successfully. For a particular
transaction to be considered successful, it must have a valid 2XX or 3XX status code,
all data must have been transferred in its entirety, and the appropriate FIN, FIN/ACK
sequence must have been completed. For HTTP 1.0 with no Keep-Alive set, an object
is considered retrieved when a FIN is received from the server. For HTTP 1.1, an
object is complete when data packets totalling the Content-Length declared in the
response header is received. For chunked transfers in HTTP 1.1, data is completely
received when the server sends the end of chunk sequence: <CR><LF>0<CR><LF>.

• http,successfulTxnsPerSec
The number of transactions completed with a valid 2XX or 3XX HTTP status code. A
transaction is considered complete and successful if the following occurs:
• HTTP 1.0: When a FIN is received from the server.
• HTTP 1.1: When data packets totalling the Content-Length declared in the
responseheader is received.
• Chunked Transfer in HTTP 1.1 (with no Content-Length declared): Data is
considered completely received when the server sends the end of the chunk string
<CR><LF>0<CR><LF>.
• http,unsuccessfulTxns
The total number of transactions in a test that terminate with one of the following
results: invalid HTTP status codes of 3XX, 4XX, or 5XX, a TCP timeout, data time-
out, connection reset, or connection errors. An HTTP redirect is not recorded as a
successful transaction. Status codes of 400 or above are counted as Unsuccessful
Transactions.
• http,unsuccessfulTxnsPerSec
The number of unsuccessful HTTP transactions per second terminated due to one of
these results:
• Invalid HTTP status codes of 3XX, 4XX, or 5 XX
• TCP timeout
• Data timeout
• Connection reset
• Connection errors.
The HTTP protocol version used is the one that you selected when you configured the
client profile for the test.
• http,txnsAwaitingResponse
The number of HTTP transactions awaiting a response.
Load Specification
The Client Statistics Load message indices display the load generation progress in terms
of the load generation units you selected when you configured the load for the test.
• loadspec,activeCawUsersCount
The active load that the client is sending to the device or infrastructure under test. The
load generation units displayed are those you selected when you configured the load
for the test.

A load is considered active from the moment the TCP connection has been established,
throughout the time the TCP connection is ended, including the time it took for the
Layer 7 protocol to complete its transaction (in the case of HTTP and HTTPS) or ses-
sion (in the case of Streaming, FTP, SMTP and POP3).
• loadspec,currentLoadSpecCount
The current load generation behavior over time. The load generation units displayed
are those you selected when you configured the load for the test. The load units
supported include Sessions, SessionsPerSecond, Connections, Connections/second,
Transactions, Transactions/second and Kilobits/second.
• loadspec,desiredLoadSpecCount
The desired load generation behavior over time. The load generation units displayed
are those you selected when you configured the load for the test. The load
units supported include Connections, ConnectionsPerSecond, Transactions,
TransactionsPerSecond and Bandwidth.
• loadspec,loadSpecType
The type of load being generated: Bandwidth, BodyBytes, Connections,
ConnectionsPerSecond, ConnectionsPerHour, Sessions, SessionsPerSecond,
SessionsPerHour, Transactions, TransactionsPerSecond, or TransactionsPerHour.
This statistic returns a value of 0 - 12. Each value is described below:
0 = Bandwidth
1 = Connections
2 = Connections/second
3 = SimUsers
4 = SimUsers/second
5 = Transactions
6 = Transactions/second
7 = BodyBytes
10 = SimUsers/hour
11 = Connections/hour
12 = Transactions/hour
Note: If you would like to see the text equivalent returned for the loadSpecType statis-
tic instead of its numerical value, we recommend you add the translation to your script.

Memory
The Client Statistics Memory message indices display information about the client’s
resource utilization level, including memory usage and internal received queue length.
• memory,isMemoryLimited
Indicates whether memory has entered MemoryThrottled state at least once since this
value was last reported. A value of 1 indicates that it has. This value does not indicate
whether the memory remains in MemoryThrottled state. (Memory throttling means the
test is running out of memory.)
• memory,linkMap
Returns the Ethernet Portal device link state, one bit per device. That is, if there are
four devices, then a value of 14 (1110) means that devices 0 through 2 are up and
device 3 is down.
• memory,mainPoolSize
The size of the main memory pool used during the test.
• memory,mainPoolUsed
The main memory pool used during the test.
• memory,packetMemoryUsed
The packet memory used during the test.
• memory,rcvQueueLength
The length of the received queue, which is the number of packets that are yet to be
processed by the client.
Miscellaneous
• testName
The name of the last test to run or current test running.
• timeElapsed
The elapsed time, in seconds, of the current test.
• timeRemaining
The remaining time, in seconds, of the current test.
POP3
The Client Statistics POP3 message indices display a summary of POP3 activity,
including POP3 sessions generated per second and active POP3 sessions. These statistics
show the network and/or device under test behavior when responding to a number of
POP3 sessions generated by the client. A POP3 session consists of a user logging into a
mailbox, issuing one or more commands (such as STAT, LIST, RETRIEVE, or DELETE),
and then quitting the mailbox.

Note: The QUIT command is automatically sent by the client and does not need to be
entered in the POP3 URL list that you create.
• pop3,abortedSessionsPerSec
The number of aborted POP3 sessions per second generated from the client. Potential
reasons for an aborted session include a TCP timeout, data timeout, connection reset,
or connection errors.
• pop3,activeSessions
The number of active POP3 sessions. A POP3 session is considered active as soon as
there is an attempt to open a TCP connection.
• pop3,attemptedSessionsPerSec
The number of attempted POP3 sessions per second generated from the client.
• pop3,successfulSessionsPerSec
The number of successful POP3 sessions per second generated from the client,
meaning the client established a connection, commands were executed, and the client
logged off.
• pop3,unsuccessfulSessionsPerSec
The number of unsuccessful POP3 sessions per second generated from the client.
PPP
The Client Statistics PPP message indices display statistics on PPP (Point-to-Point
Protocol) traffic being generated by the client, based on PPP configurations. These
statistics show the network and/or device under test behavior when responding to PPP
traffic generated by the client.
• ppp,sessionsActive
The number of active PPP sessions.
• ppp,sessionsAttempted
The number of attempted PPP sessions.
• ppp,sessionsDisconnected
The number of PPP sessions that disconnected successfully.
• ppp,sessionsFailedAuth
The number of PPP sessions that failed authentication.
• ppp,sessionsFailedOther
The number of PPP sessions that failed for other reasons.
• ppp,sessionsFailedReleases
The number of PPP sessions that failed because the PPP connection was not
properly closed.

• ppp,sessionsPacketLossRateAvg
The average number of PPP packets lost (%) for a session.
• ppp,sessionsPacketLossRateMax
The maximum number of PPP packets lost (%) for a session.
• ppp,sessionsSetupRate
The number of new PPP sessions established.
• ppp,sessionsSetupTimeAvg
The average time to establish a new PPP session.
• ppp,sessionsSetupTimeMax
The maximum time to establish a new PPP session.
• ppp,sessionsSetupTimeMin
The minimum time to establish a new PPP session.
• ppp,sessionsSuccessful
The number of successful PPP sessions.
• ppp,sessionsTeardownRate
The number of PPP sessions that terminated.
• ppp,sessionsTeardownTimeAvg
The average time to terminate a PPP session.
• ppp,sessionsThroughputMax
The maximum number of PPP packets sent/received for a session.
• ppp,totalRxConfigAck
The number of packets for PPP Total Received Config Ack.
• ppp,totalRxConfigNak
The number of packets for PPP Total Received Config Nack.
• ppp,totalRxConfigReject
The number of packets for PPP Total Received Config Reject.
• ppp,totalRxConfigReq
The number of packets for PPP Total Received Config Request.
• ppp,totalRxEchoReply
The number of packets for PPP Total Received Echo Reply.
• ppp,totalRxEchoReq
The number of packets for PPP Total Received Echo Request.
• ppp,totalRxTermAck
The number of packets for PPP Total Received Terminate Ack.

• ppp,totalRxTermReq
The number of packets for PPP Total Received Terminate Request.
• ppp,totalTxConfigAck
The number of packets for PPP Total Transmitted Config Ack.
• ppp,totalTxConfigNak
The number of packets for PPP Total Transmitted Config Nack.
• ppp,totalTxConfigReject
The number of packets for PPP Total Transmitted Config Reject.
• ppp,totalTxConfigReq
The number of packets for PPP Total Transmitted Config Request.
• ppp,totalTxEchoReply
The number of packets for PPP Total Transmitted Echo Reply.
• ppp,totalTxEchoReq
The number of packets for PPP Total Transmitted Echo Request.
• ppp,totalTxTermAck
The number of packets for PPP PPP Total Transmitted Terminate Ack.
• ppp,totalTxTermReq
The number of packets for PPP Total Transmitted Terminate Request.
PPPoE
The Client Statistics PPPoE message indices display statistics on PPPoE (Point-to-Point
over Ethernet (PPPoE) Protocol) traffic being generated by the client, based on PPPoE
configurations.
• pppoe,totalRxPADI
The number of received packets for PADI.
• pppoe,totalRxPADO
The number of received packets for PADO.
• pppoe,totalRxPADR
The number of received packets for PADR.
• pppoe,totalRxPADS
The number of received packets for PADS.
• pppoe,totalRxPADT
The number of received packets for PADT.

• pppoe,totalTxPADI
The number of transmitted packets for PADI.
• pppoe,totalTxPADO
The number of transmitted packets for PADO.
• pppoe,totalTxPADR
The number of transmitted packets for PADR.
• pppoe,totalTxPADS
The number of transmitted packets for PADS.
• pppoe,totalTxPADT
The number of transmitted packets for PADT.
Simulated Users
• simusers,mCawUsersAnimated
The number of SimUsers that have been born or reinstated after being suspended. The
counter increments whenever a birth or reinstate transition occurs, and is decremented
whenever a suspend or premature death occurs.
• simusers,mCawUsersAnimating
The number of SimUsers that are actively traversing through the action list, and are not
waiting for an external event to occur (such as query to a database). The counter incre-
ments whenever a birth or reinstate transition occurs, and is decremented whenever a
suspend or premature death occurs.
• simusers,mCawUsersBorn
Indicates the rate or frequency, calculated by the change in the number of SimUsers
born each sampling interval. Increments whenever a SimUser goes from the Conceiv-
ing state to the Animated state.
• simusers,mCawUsersNatural
The total number of SimUsers who have successfully executed the statements in the
entire action list. This occurs when each SimUser reaches the end of their action list.
• simusers,mCawUsersSleeping
The frequency at which the Natural death is occurring. This rate is derived from the
increase or decrease in the cumulative counter for Natural death.
• simusers,mCawUsersSlept
The frequency at which the Natural and Premature death transitions are occurring. This
number is calculated as the sum of Natural Death and Premature death rates.

• simusers,mCawUsersSuspended
The total number of SimUsers that have been suspended. This counter increments
whenever a Suspend transition occurs. A suspend transition can occur when the system
is in an error condition, such as when it has limited available memory. The total num-
ber of suspended SimUsers can be greater than the total number born when the error
condition is of a long duration, and the same SimUser is repeatedly suspended and
reinstated.
• simusers,mCawUsersSuspending
The Suspend transition occurs when an error condition happens while an animated
SimUser is traversing through the action list. The Suspend rate is the frequency at
which the transition from Animating to Suspending is occurring. This rate is derived
from the increase in the Suspended cumulative counter and is reported each sampling
interval.
• simusers,mCawUsersUnnatural
The total number of SimUsers who have not, and will never, successfully execute the
statements in the action list.
• simusers,mCpuUtilized
The amount of idle time available. A lower number means there are more CPU
resources being used and therefore, less idle time. A higher number means you have
more idle time (the CPU is not being used that much).
• simusers,mMainMemoryPoolSize
• simusers,mMainMemoryPoolUsed
The memory usage during the test, including packet memory used, main memory pool,
and main memory pool size.
• simusers,mMemoryThrottledTime
The amount of time that memory has been throttling.
• simusers,mPacketMemoryPoolUsed
SMTP
The Client Statistics SMTP message indices display a summary of SMTP activity,
including SMTP sessions generated per second and active SMTP sessions. These statistics
SMTP sessions generated by the client. An SMTP session consists of a user connecting to
the SMTP port through the initial HELO command, sending an email message by issuing
various commands (such as MAIL, RCPT, and DATA) and closing the session by issuing
the QUIT command.

Note: The QUIT command is automatically sent by the client and does not need to be
entered in the SMTP URL list that you create.
• smtp,abortedSessionsPerSec
The number of aborted SMTP sessions per second. Potential reasons for an aborted
session include a TCP timeout, data timeout, connection reset, or connection errors.
• smtp,activeSessions
The number of active SMTP sessions. An SMTP session is considered active as soon
as the client sends the initial HELO, and is considered closed when the SMTP server's
ACK for the client's QUIT command has been received.
• smtp,attemptedSessionsPerSec
The number of attempted SMTP sessions per second.
• smtp,successfulSessionsPerSec
The number of successful SMTP sessions per second, meaning the client established a
connection, commands were executed, and the client logged off.
• smtp,unsuccessfulSessionsPerSec
The number of unsuccessful SMTP sessions per second.
Streaming
The Client Statistics Streaming message indices display a summary of streaming activity
and Quality of Service metrics, including concurrent streams and channels, streaming
response time, bandwidth utilization, and packet loss. The following streaming protocols
are supported:
• QuickTime (Standards-based RTSP/RTP)
• Microsoft Windows Media
• Video On Demand (VoD) Multicasting RTP streams (that is, mcrtp://… channels
in the URL list that you create).
• streaming,bandwidth30_100K
The number of streams that flow between 30 kb/s and 100 kb/s.
• streaming,bandwidth300K_1M
The number of streams that flow Between 300 kb/s and 1 mb/s.
• streaming,bandwidthGT1M
The number of streams that flow at greater than 1 mb/s.
• streaming,bandwidthLT30K
The number of streams that flow at less than 30kb/s.

• streaming,currentActiveChannels
The number of concurrent channels that are active.
• streaming,currentActiveStreams
The number of concurrent streams that are active. A stream is considered active from
the time the streaming protocol conversation has been established to the time the
conversation ends.
A stream can be composed of one or more channels. Typically, the stream will have
two channels: one for video and one for audio. If the stream is a radio broadcast, it will
have only one channel, the audio channel. In most cases, the number of channels is
double the number of streams.
Note: Streaming sessions tend to have a longer duration than HTTP transactions,
since the stream being played can extend in duration from a few seconds to a few
hours. Therefore, you may see a number of streams active for a long time.
• streaming,packetLossRate_0_P1pct
The amount of packet loss between 0 and 0.1 percent that occurred during the stream
transmission.
• streaming,packetLossRate_0pct
The amount of 0 percent packet loss that occurred during the stream transmission.
• streaming,packetLossRate_2_5pct
The amount of packet loss between 2 and 5 percent that occurred during the stream
transmission.
• streaming,packetLossRate_GT5pct
The amount of packet loss greater than 5 percent that occurred during the stream
transmission.
• streaming,packetLossRate_P1_P5pct
The amount of packet loss between 0.1 and 0.5 percent that occurred during the stream
transmission.
• streaming,packetLossRate_P5_2pct
The amount of packet loss between 0.5 and 2 percent that occurred during the stream
transmission.
• streaming,responseTime
The elapsed time, in milliseconds, from the time the server received a PLAY request,
to the time the server sends the first data byte.
TCP
The Client Statistics TCP message indices display relevant TCP statistics that show the
amount of load generated and quality of service metrics, such as response times and
established TCP connections.

• tcp,attemptedConnRate
The number of attempted TCP connections per second generated from the client. A
TCP connection is considered attempted as soon as the SYN packet is sent.
• tcp,attemptedConns
The number of TCP connections that were attempted when the SYN was sent.
• tcp,currentEstablishedConns
The number of TCP connections that were successfully established when the three-
way handshake (SYN/ACK/FIN) was completed.
• tcp,currentEstimatedServerProcTime
The average amount of time in milliseconds (ms) it takes to receive the first data byte
back from the server.
• tcp,currentTimeToFirstByte
The average amount of time in milliseconds (ms) it takes for the server to receive the
first data byte.
• tcp,currentTimeToSynAck
The average amount of time in milliseconds (ms) the server takes to respond with the
TCP SYN/ACK.
• tcp,establishedConnRate
The number of established TCP connections per second generated from the client. A
TCP connection is considered established as soon as the 3-way handshake has been
completed (SYN, SYN/ACK, ACK).
• tcp,maxEstimatedServerProcTime
The maximum amount of time in milliseconds (ms) it takes to receive the first data
byte back from the server.
• tcp,maxTimeToFirstByte
The maximum amount of time in milliseconds (ms) it takes for the server to receive the
first data byte.
• tcp,maxTimeToSynAck
The maximum amount of time in milliseconds (ms) the server takes to respond with
the TCP SYN/ACK.
• tcp,minEstimatedServerProcTime
The minimum amount of time in milliseconds (ms) it takes to receive the first data byte
back from the server.
• tcp,minTimeToFirstByte
The minimum amount of time in milliseconds (ms) it takes for the server to receive the
first data byte

• tcp,minTimeToSynAck
The minimum amount of time in milliseconds (ms) the server takes to respond with the
TCP SYN/ACK.
TCPState
The Client TCP State Statistics include the total number of connections that were in each
state since the start of the test.
• tcpstate,closed_to_Listen
The total number of TCP connections that transitioned from the Closed state to the
Listen state.
• tcpstate,closed_to_SynSent
SynSent state.
• tcpstate,closeWait_to_Closed
The total number of TCP connections that transitioned from the CloseWait state to the
Closed state.
• tcpstate,closeWait_to_LastAck
LastAck state.
• tcpstate,closing_to_Closed
The total number of TCP connections that transitioned from the Closing state to the
Closed state.
• tcpstate,closing_to_TimeWait
TimeWait state.
• tcpstate,estb_to_Closed
The total number of TCP connections that transitioned from the Established state to the
Closed state.
• tcpstate,estb_to_CloseWait
CloseWait state.
• tcpstate,estb_to_FinWait1
FinWait1 state.

• tcpstate,finWait1_to_Closed
The total number of TCP connections that transitioned from the FinWait1 state to the
Closed state.
• tcpstate,finWait1_to_Closing
Closing state.
• tcpstate,finWait1_to_FinWait2
FinWait2 state.
• tcpstate,finWait1_to_TimeWait
TimeWait state.
Closed state.
TimeWait state.
• tcpstate,lastAck_to_Closed
The total number of TCP connections that transitioned from the LastAck state to the
Closed state.
• tcpstate,listen_to_Closed
The total number of TCP connections that transitioned from the Listen state to the
Closed state.
• tcpstate,listen_to_SynRcvd
The total number of TCP connections that transitioned from the Listen state to the Syn-
Received state.
• tcpstate,synRcvd_to_Closed
The total number of TCP connections that transitioned from the SynReceived state to
the Closed state.
• tcpstate,synRcvd_to_Estb
the Established state.
• tcpstate,synSent_to_Closed
The total number of TCP connections that transitioned from the SynSent state to the
Closed state.

• tcpstate,synSent_to_Estb
Established state.
• tcpstate,synSent_to_SynRcvd
SynReceived state.
• tcpstate,timeWait_to_Closed
The total number of TCP connections that transitioned from the TimeWait state to the
Closed state.
Telnet
The Client Statistics Telnet message indices display a summary of Telnet activity,
including Telnet connections generated per second and active Telnet connections. These
statistics show the network and/or device under test behavior when responding to a
number of Telnet connections generated by the client.
Note: The Telnet commands that you configure in the Client Profiles tab include both
preauthorization commands and normal Telnet commands. You also configure option
negotiation to be on or off in the Telnet Client emulation pane in the Client Profiles tab.
• telnet,abortedConnsPerSec
The number of aborted sessions per second. Potential reasons for an aborted session
include a TCP timeout, data timeout, connection reset, or connection errors.
• telnet,activeConns
The Telnet session minimum, maximum, and average duration in milliseconds.
• telnet,attemptedConnsPerSec
The number of attempted Telnet sessions per second.
• telnet,successfulConnsPerSec
The number of sessions per second that were completed successfully, meaning the
client established a connection, commands were executed, and the client logged off.
• telnet,unsuccessfulConnsPerSec
The number of sessions per second in a test that terminated unsuccessfully.
URL
These message indices display URL response times.
• url,currentRespTimePerPage
The average amount of time in milliseconds (ms) it takes to receive the level-2 objects
(the embedded links and graphics) from the server.

• url,currentRespTimePerUrl
The current amount of time in milliseconds (ms) it takes to receive a level-2 object
(main page or file) from the server.
• url,maxRespTimePerPage
The maximum amount of time in milliseconds (ms) it takes to receive the level-2
objects (the embedded links and graphics) from the server.
• url,maxRespTimePerUrl
The maximum amount of time in milliseconds (ms) it takes to receive a level-1 object
• url,minRespTimePerPage
The minimum amount of time in milliseconds (ms) it takes to receive the level-2
objects (the embedded links and graphics) from the server.
• url,minRespTimePerUrl
The minimum amount of time in milliseconds (ms) it takes to receive a level-1 object
SIP
The Client Statistics SIP message indices display a summary of SIP activity, including SIP
sessions generated per second and active SIP sessions. These statistics show the network
and/or device under test behavior when responding to a number of SIP sessions generated
by the client.
• sip,activeConnsPerSec
The number of active SIP sessions per second generated from the client. A SIP session
is considered active as soon a call is accepted, and closed after the call is terminated.
• sip,attemptedConnsPerSec
The number of attempted SIP sessions per second generated from the client.
• sip,successfulConnsPerSec
The number of successful SIP sessions per second generated from the client.
• sip,unsuccessfulConnsPerSec
The number of unsuccessful SIP sessions per second generated from the client.
• sip,rtpPacketsSentPerSec
The number of RTP packets sent per second. RTP data streams are used to carry the
voice data.
• sip,rtpPacketsRecvPerSec
The number of RTP packets received per second. RTP data streams are used to carry
the voice data.

IPSEC
The Client Statistics IPSec message indices display a summary of IPSec tunnel activity
during the Phase 1 and Phase 2 negotiation processes. These statistics show the network
and/or device under test behavior when establishing IPSec tunnels.
• ipsec,aggressiveAttempts
The number of attempted Phase 1 Aggressive mode tunnels per second.
• ipsec, aggressiveTimeouts
The number of message timeouts for Phase 1 Aggressive mode.
• ipsec, aggressiveFailuresTimeoutRetry
The number of failed Phase 1 Aggressive mode tunnels per second due to a timeout.
• ipsec,aggressiveFailuresOther
The number of failed Phase 1 Aggressive mode tunnels per second due to a reason
other than a timeout.
• ipsec,aggressiveSuccesses
The number of successful Phase 1 Aggressive mode tunnels per second.
• ipsec,cumulativeMainModeAttempts
The number of attempted Phase 1 Main mode tunnels.
• ipsec,cumulativeMainModeSuccesses
The number of successful Phase 1 Main mode tunnels.
• ipsec,cumulativeAggressiveAttempts
The number of attempted Phase 1 Aggressive mode tunnels.
• ipsec,cumulativeAggressiveSuccesses
The number of successful Phase 1 Aggressive mode tunnels.
• ipsec,cumulativeQuickAttempts
The number of attempted Phase 2 Quick mode tunnels.
• ipsec,cumulativeQuickSuccesses
The number of successful Phase 2 Quick mode tunnels.
• ipsec,mainModeAttempts
The number of attempted Phase 1 Main mode tunnels per second.
• ipsec,mainModeTimeouts
The number of message timeouts for Main mode.
• ipsec,mainModeFailuresTimeoutRetry
The number of failed Phase 1 Main mode tunnels per second due to a timeout.

• ipsec,mainModeFailuresOther
The number of failed Phase 1 Main mode tunnels per second due to reasons other than
a timeout.
• ipsec,mainModeSuccesses
The number of successful Phase 1 Main mode tunnels per second.
• ipsec,SAExpirationsPhase1
The number of expired Phase 1 SAs (Security Associations). These expire based on the
Phase 1 IKE Lifetime.
• ipsec,SAExpirationsPhase2
The number of expired Phase 2 SAs (Security Associations). These expire based on the
the Phase 2 SaLD Lifetime.
• ipsec,quickAttempts
The number of attempted Phase 2 Quick mode tunnels per second.
• ipsec,quickTimeouts
The number of message timeouts for Quick mode.
• ipsec,quickFailuresTimeoutRetry
The number of timeouts in a Phase 2 Quick mode tunnels per second due to timeouts.
• ipsec,quickFailuresOther
The number of failed Phase 2 Quick mode tunnels per second due to reasons other than
a timeout.
• ipsec,quickSuccesses
The number of successful Phase 2 Quick mode tunnels per second.
• ipsec,currentISAKMPSas
The number of successful Phase 1 (ISAKMP) negotiations.
• ipsec,currentIPSecSas
The number of successful Phase 2 (IPSec) SA (Security Association) negotiations.
• ipsec,XAuthAttempts
The number of attempted authentications, using XAuth (Extended Authentication) for
phase 1 (Remote Access tunnel only).
• ipsec,XAuthFailures
The number of failed authentications, using XAuth (Extended Authentication) for
• ipsec,XAuthSuccesses
The number of successful authentications, using XAuth (Extended Authentication) for

• ipsec, infoPackets
The number of informational messages.
• ipsec,dpdRequestsReceived
The number of DPD (Dead Peer Detection) requests received. DPD is used to query
whether the other end of the tunnel is up.
• ipsec,dpdResponsedSent
The number of DPD (Dead Peer Detection) responses sent. DPD is used to query
whether the other end of the tunnel is up.
The following three packet statistics correspond to the "ESP Packets" column in the Layer
4-7 Application’s "ClientStats" window. These numbers are cumulative statistics:
• ipsec,packetsDiscarded
The number of discarded IP packets, using ESP (Encapsulating Security Payload) for
encryption.
• ipsec,packetsDecrypted
The number of decrypted IP packets, using ESP (Encapsulating Security Payload) for
encryption.
• ipsec,packetsEncrypted
The number of encrypted IP packets, using ESP (Encapsulating Security Payload) for
encryption.
The IPSec incoming and outgoing traffic in kbps are represented in the following two
statistics variables:
• ipsec,octetsDecrypted
The number of decrypted kbps, using ESP (Encapsulating Security Payload) for
encryption. (Octets are converted to kbps)
• ipsec,octetsEncrypted
The number of encrypted kbps, using ESP (Encapsulating Security Payload) for
encryption. (Octets are converted to kbps)
The IPSec incoming and outgoing traffic in kbps statistics do not appear with these
names in the realtime.csv result file. Instead, they are displayed as "IPSec: Incoming
Traffic (kbps)" and "IPSec: Outgoing Traffic (kbps)."

MM4
The Client Statistics MM4 message indices display a summary of MM4 activity, including
MM4 forward transactions generated per second and total MM4 forward transactions.
These statistics show the network and/or device under test behavior when responding to a
number of MM4 transactions generated by the client.
• mm4,totalAttemptedForwardTransactions
The total number of attempted MM4 forward transactions generated from the client.
• mm4,ttotalSuccessfulForwardTransactions
The total number of successful MM4 forward transactions generated from the client.
• mm4,ttotalUnsuccessfulForwardTransactions
The total number of unsuccessful MM4 forward transactions generated from the client.
• mm4,ttotalAbortedForwardTransactions
The total number of aborted MM4 forward transactions generated from the client.
• mm4,tattemptedForwardTransactionsPerSec
The number of attempted MM4 forward transactions generated from the client.
• mm4,tsuccessfulForwardTransactionsPerSec
The number of successful MM4 forward transactions generated from the client.
• mm4,tunsuccessfulForwardTransactionsPerSec
The number of unsuccessful MM4 forward transactions generated from the client.
• mm4,tabortedForwardTransactionsPerSec
The number of aborted MM4 forward transactions generated from the client.
• mm4,taverageForwardResponseTime
The average MM4 forward response time, which is measured from the time of sending
the MM4_forward.REQ message until receiving the MM4_forward.RES message
from the MMSC (Multimedia Messaging Service Center).

Server Statistics Message Indices
Server Statistics Message Indices

The Server statistics message indices, like the Client statistics message indices, are
different sets of filters you can use to determine what data gets passed back to the callback
function when it is invoked.
The output file contains detailed summary test results that indicate how the server and the
system under test behaved during the assessment. It lists all the configured Test
Parameters, plus Application, Stack, and Driver statistics. For record-keeping purposes,
the date and time of the test start and end are also recorded. Viewing results requires an
application that reads .csv format.
How to Use Them

The RegisterStatsCallBack function includes a filter list parameter. Each item
within the list represents a glob-style pattern and only indices that match one (or more) of
the filter patterns are included in the callbackData list.
The following example uses the set command to specify which data items you want to see.
set filterList [list <pop3*>]

For a server test running, the above filter list will cause all pop3 indices to be present in
the callbackData:
If the filterList parameter is omitted, then no filtering of the statistics will occur and
the callback function will be passed the complete statistics message.

Filters to Use for Server Statistics

This section contains the complete list of message indices you can use when you create
filters on server statistics:
• TCP Capture-Replay
• UDP Capture-Replay
• DNS
• Driver
• FTP
• HTTP
• Memory
• Miscellaneous
• POP3
• SMTP
• Streaming
• TCP
• TCP Connections
• TCP State
• Telnet
• SIP
TCP Capture-Replay
The Server Statistics TCP Capture-Replay message indices display a summary of
Capture-Replay TCP session activity, including sessions generated per second and active
responding to Capture-Replay TCP sessions generated by the server.
• capRepTcp,abortedConnsPerSec
The number of aborted Capture-Replay TCP sessions per second generated by the
server.
• capRepTcp,activeConns
The number of active Capture-Replay TCP sessions.
• capRepTcp,attemptedConnsPerSec
The number of attempted Capture-Replay TCP sessions per second generated by the
server.

• capRepTcp,successfulConnsPerSec
The number of successful Capture-Replay TCP sessions per second generated by the
server.
• capRepTcp,unsuccessfulConnsPerSec
The number of unsuccessful Capture-Replay TCP sessions per second generated by the
server.
UDP Capture-Replay
The Server Statistics UDP Capture-Replay message indices display a summary of
Capture-Replay UDP session activity, including sessions generated per second and active
responding to Capture-Replay UDP sessions generated by the server.
• capRepUdp,activeConns
The number of active Capture-Replay UDP sessions.
• capRepUdp,attemptedConnsPerSec
The number of attempted Capture-Replay UDP sessions per second generated by the
server.
• capRepUdp,successfulConnsPerSec
The number of successful Capture-Replay UDP sessions per second generated by the
server.
• capRepUdp,unsuccessfulConnsPerSec
The number of unsuccessful Capture-Replay UDP sessions per second generated by
the server.
DNS
The Server Statistics DNS message indices display a summary of DNS activity, including
DNS queries generated per second and active DNS queries. These statistics show the
network and/or device under test behavior when responding to a number of DNS queries
generated by the server. DNS entries in the URL list that you create simulate a DNS client
sending different types of DNS name resolution requests to a DNS server.
• dns,attemptedQueriesPerSec
The number of attempted DNS queries per second generated by the server.
• dns,successfulQueriesPerSec
The number of successful DNS queries per second generated by the server. This total
includes all query types.
• dns,unsuccessfulQueriesPerSec
The number of unsuccessful DNS queries per second generated by the server.

Driver
The Server Statistics Driver message indices display bandwidth utilization, both incoming
and outgoing, showing the bandwidth being used by the server and the network and/or
device under test. Other relevant metrics include packet traffic per second.
• driver,rxBandwidth
The average incoming bandwidth traffic (sent to the server by the device under test).
• driver,txBandwidth
The average outgoing bandwidth traffic (sent by the server to the device under test).
• driver,linkMap
The total number of mapping errors. A map error is an internal error condition, in
which the client attempts to delete a connection that it cannot find on its TCP map for
the duration of the test.
• driver,maxRxBandwidth
The maximum incoming bandwidth traffic (sent to the server by the device under test).
• driver,maxTxBandwidth
The maximumoutgoing bandwidth traffic (sent by the server to the device under test).
• driver,rcvQueueLength
processed by the server.
• driver,rxPacketRate
The incoming number of packets per second (sent to the server by the device
under test).
• driver,txPacketRate
The outgoing number of packets per second (sent by the server to the device
under test).
FTP
The Server Statistics FTP message indices display a summary of FTP activity, including
data transfer rate, FTP sessions generated per second, and the number of file transfers per
second. These statistics show the network and/or device under test behavior when
responding to a number of FTP sessions generated by the server. They answer these
important questions about the network or device under test:
• How many concurrent FTP sessions can be supported?
• How many FTP sessions per second can be sent?
• How much data per second can be sent?

• ftp,attemptedSessionsPerSec
The number of attempted FTP sessions per second generated from the server.
• ftp,dataTransferRate
The amount of data, in kbytes per second, sent by the server to the FTP infrastructure.
• ftp,fileTransferRate
The number of files being transferred per second. The server supports the transfer of
one file per session.
• ftp,successfulSessionsPerSec
The number of successful FTP sessions per second generated by the server.
• ftp,unsuccessfulSessionsPerSec
The number of unsuccessful FTP sessions per second generated by the server.
HTTP
The Server Statistics HTTP message indices display HTTP statistics, such as current
HTTP transactions per second, and open HTTP transactions.
• http,avgTxnsPerSec
The average number of HTTP transactions generated per second.
• http,completedTxns
The number of HTTP transactions successfully completed per second.
• http,openTxns
The number of open HTTP transactions. An HTTP transaction is considered open from
the time the request is received, to the time the last data byte of the response is sent.
• http,txnsPerSec
The number of HTTP transactions generated per second.
Memory
The Server Statistics Memory message indices display information about the server’s
resource utilization level, including memory usage and internal received queue length.
• memory,isMemoryLimited
Indicates whether memory has entered MemoryThrottled state at least once since this
value was last reported. A value of 1 indicates that it has. This value does not indicate
whether the memory remains in MemoryThrottled state. (Memory throttling means the
test is running out of memory.)
• memory,mainPoolSize

• memory,mainPoolUsed
The memory usage during the test, including packet memory used, main memory pool,
and main memory pool size.
• memory,packetMemoryUsed
• memory,rcvQueueLength
processed by the server.
Miscellaneous
• testName
The name of the last test to run or current test running.
• timeElapsed
The elapsed time, in seconds, of the current test.
• timeRemaining
The remaining time, in seconds, of the current test.
POP3
The Server Statistics POP3 tab message indices display a summary of POP3 activity,
including POP3 sessions generated per second and active POP3 sessions. These statistics
POP3 sessions generated by the server. A POP3 session consists of a user logging into a
mailbox, issuing one or more commands (such as STAT, LIST, RETRIEVE, or DELETE),
and then quitting the mailbox.
• pop3,abortedSessionsPerSec
The number of aborted POP3 sessions per second generated by the server. Potential
reasons for an aborted session include a TCP timeout, data timeout, connection reset,
or connection errors.
• pop3,activeSessions
The number of active POP3 sessions. A POP3 session is considered active as soon as
there is an attempt to open a TCP connection.
• pop3,attemptedSessionsPerSec
The number of attempted POP3 sessions per second generated by the server.
• pop3,successfulSessionsPerSec
The number of successful POP3 sessions per second. A session is considered
successful once it has finished in its entirety (that is, the TCP connection established,
the user logged in to the mailbox, executed some commands, logged out of the
mailbox, and the TCP connection closed).

• pop3,unsuccessfulSessionsPerSec
The number of unsuccessful POP3 sessions per second. A session can be unsuccessful
for a number of reasons, such as wrong username, wrong password, unavailable %
activated in the POP3 settings, and so on.
SMTP
The Server Statistics message indices display a summary of SMTP activity, including
SMTP sessions generated per second and active SMTP sessions. These statistics show the
network and/or device under test behavior when responding to a number of SMTP
sessions generated by the server. An SMTP session consists of a user connecting to the
SMTP port through the initial HELO command, sending an email message by issuing
various commands (such as MAIL, RCPT, and DATA) and closing the session by issuing
the QUIT command.
• smtp,abortedSessionsPerSec
The number of aborted SMTP sessions per second. Potential reasons for an aborted
session include a TCP timeout, data timeout, connection reset, or connection errors.
• smtp,activeSessions
The number of active SMTP sessions. An SMTP session is considered active as soon
as the client sends the initial HELO, and is considered closed when the SMTP server's
ACK for the client's QUIT command has been received.
• smtp,attemptedSessionsPerSec
The number of attempted SMTP sessions per second.
• smtp,successfulSessionsPerSec
The number of successful SMTP sessions per second.
• smtp,unsuccessfulSessionsPerSec
The number of unsuccessful SMTP sessions per second.
Streaming
The Server Statistics Streaming message indices display a summary of streaming activity
and Quality of Service metrics, including concurrent streams and channels, streaming
response time, and bandwidth utilization. The following streaming protocols are
supported:
• QuickTime (Standards-based RTSP/RTP)
• Microsoft Windows Media
• Video On Demand (VoD) Multicasting RTP streams (that is, mcrtp://… channels
in the URL list that you create).

• streaming,bandwidth300K_1M
The number of streams that flow Between 300 kb/s and 1 mb/s.
• streaming,bandwidthGT1M
The number of streams that flow at greater than 1 mb/s.
• streaming,bandwidthLT30K
The number of streams that flow at less than 30kb/s.
• streaming,currentActiveChannels
The number of concurrent channels that are active.
• streaming,currentActiveStreams
The number of concurrent streams that are active. A stream is considered active from
the time the streaming protocol conversation has been established to the time the
conversation ends.
A stream can be composed of one or more channels. Typically, the stream will have
two channels: one for video and one for audio. If the stream is a radio broadcast, it will
have only one channel, the audio channel. In most cases, the number of channels is
double the number of streams.
Note: Streaming sessions tend to have a longer duration than HTTP transactions,
since the stream being played can extend in duration from a few seconds to a few
hours. Therefore, you may see a number of streams active for a long time.
• streaming,responseTime
The elapsed time, in milliseconds, from the time the server received a PLAY request,
to the time the server sends the first data byte.
TCP
The Server Statistics TCP message indices display the TCP response times observed by
the server, including response time to first GET request, response time to first ACK, and
response time to connection close.
The following TCP response times are displayed:
• tcp,avgToAckOfFirstTxData
The average time, in milliseconds, needed to get the first client ACK for the response
data sent by the server.
• tcp,avgToConnClose
The average time, in milliseconds, needed to close the TCP connection.

• tcp,avgToFirstGet
The average time, in milliseconds, that the server waited before getting an initial
request from one of the clients.
• tcp,currentTimeToAckOfFirstTxData
The current time, in milliseconds, needed to get the first client ACK for the response
data sent by the server.
• tcp,currentTimeToConnClose
The current time, in milliseconds, needed to close the TCP connection.
• tcp,currentTimeToFirstGet
The current time, in milliseconds, that the server waited before getting an initial
request from one of the clients.
TCP Connections
The Server TCP Connection Statistics include the application connections initiated by the
Application Layer and various events that indicate how the connections were terminated.
• tcpConn,averageConnsPerSec
The average number of new application connections initiated per second.
• tcpConn,closedWithError
The number of application connections that ended due to an error condition. Error
conditions include: connection error, data timeout, and connection timeout.
• tcpConn,closedWithNoError
The total number of application connections that initiated the close process through a
close message from the Application Layer.
• tcpConn,closedWithReset
The total number of application connections that were reset due to a reset message sent
by the client.
• tcpConn,connsPerSec
The actual number of new application connections initiated per second.
• tcpConn,maxOpenConns
The maximum number of application connections left open at the end of the test.
• tcpConn,openConns
The total number of remaining open TCP connections at the end of the test.

TCP State
The Server TCP State Transition incremental statistics include the number of connections
that transitioned from one state to another. These statistics are logged at a preconfigured
sampling interval. You can set this interval with the RunTimeStatistics parameter.
.
• tcpstate,closed_to_Listen
Listen state.
• tcpstate,closed_to_SynSent
SynSent state.
• tcpstate,closeWait_to_Closed
Closed state.
• tcpstate,closeWait_to_LastAck
LastAck state.
• tcpstate,closing_to_Closed
Closed state.
• tcpstate,closing_to_TimeWait
TimeWait state.
• tcpstate,estb_to_Closed
Closed state.
• tcpstate,estb_to_CloseWait
CloseWait state.
• tcpstate,estb_to_FinWait1
FinWait1 state.
Closed state.

• tcpstate,finWait1_to_Closing
Closing state.
• tcpstate,finWait1_to_FinWait2
FinWait2 state.
TimeWait state.
Closed state.
TimeWait state.
• tcpstate,lastAck_to_Closed
The total number of TCP connections that transitioned from the LastAck state to the
Closed state.
• tcpstate,listen_to_Closed
Closed state.
• tcpstate,listen_to_SynRcvd
SynReceived state.
• tcpstate,synRcvd_to_Closed
the Closed state.
• tcpstate,synRcvd_to_Estb
• The total number of TCP connections that transitioned from the SynReceived state to
the Established state.
• tcpstate,synSent_to_Closed
Closed state.
• tcpstate,synSent_to_Estb
Established state.

• tcpstate,synSent_to_SynRcvd
SynReceived state.
• tcpstate,timeWait_to_Closed
The total number of TCP connections that transitioned from the TimeWait state to the
Closed state.
Telnet
The Server Telnet Statistics include Telnet session totals.
• telnet,abortedSessionsPerSec
The number of aborted sessions per second. Potential reasons for an aborted session
include a TCP timeout, data timeout, connection reset, or connection errors.
• telnet,activeSessions
The number of active Telnet sessions.
• telnet,attemptedSessionsPerSec
The number of attempted Telnet sessions per second.
• telnet,successfulSessionsPerSec
The number of sessions per second that were completed successfully, meaning the
client established a connection, commands were executed, and the client logged off.
• telnet,unsuccessfulSessionsPerSec
The number of sessions per second in a test that terminated unsuccessfully.
SIP
The Server Statistics SIP message indices display a summary of SIP activity, including
SIP sessions generated per second and active SIP sessions. These statistics show the
network and/or device under test behavior when responding to a number of SIP sessions
generated by the server.
• sip,activeConnsPerSec
The number of active SIP sessions per second.
• sip,attemptedConnsPerSec
The number of attempted SIP sessions per second generated by the server.
• sip,successfulConnsPerSec
The number of successful SIP sessions per second generated by the server.
• sip,unsuccessfulConnsPerSec
The number of unsuccessful SIP sessions per second generated by the server.

• sip,rtpPacketsSentPerSec
The number of RTP packets sent per second.
• sip,rtpPacketsRecvPerSec
The number of RTP packets received per second.
MM4
The Server Statistics MM4 message indices display a summary of MM4 activity, including
MM4 forward responses generated per second and various response times. These statistics
show the network and/or device under test behavior when responding to a number of MM4
messages generated by the server.
• mm4,forwardResponsesSentPerSec
The number of MM4 forward responses per second generated from the server and various
response times.
• mm4,deliveryReportResponseTime
The delivery report response time, which is measured from the time of sending the
MM4_delivery_report.REQ message until receiving the MM4_delivery_report.RES
message from the originator MMSC (Multimedia Messaging Service Center).
• mm4,readReplyReportResponseTime
The read replay report response time, which is measured from the time of sending the
the MM4_read_reply_report.REQ message until receiving the
MM4_read_reply_report.RES message from the originator MMSC (Multimedia
Messaging Service Center).

Appendix B
Sample Files
The Scripting API is packaged with several sample configuration array files and test
scripts. This appendix includes a printout of the .tcl configuration array named config and
the test.tcl test script for your reference. These printed copies, while accurate at the time of
this printing, may become out of date. Therefore, please refer to the configuration files and
test scripts in your Scripting API for the Layer 4-7 Application package for the most
recent versions: They are located in the directory named SampleTests.
In this appendix...
• Sample Configuration File . . . . 264
• Sample Test Script . . . . 281
Appendix B: Sample Files
Sample Configuration File

Note: Due to the set page width, some of the lines of sample code line have wrapped to
the next line. In these instances, although you will not see a Tcl line continuation character
(\), the content of the next line is considered part of the previous line.
The contents of the sample Spirent TestCenter config.tcl script is as follows:
######################################################################
####
#
# GUI2Script Generated Configuration
#
######################################################################
####
#
# COMMANDER INFO
# - Originating Test Name : AdvDevOpenConns
# - Originating Project Name : Validation
#
######################################################################
####
# Script Created : 2007/08/27 11:58:19
# Script Checksum : D192C04E0215086911F6909CBA9EB20E
######################################################################
####
#
# Build up a Spirent TestCenter provision list -
#
# <PortID> <PortMAC> <PortMedia> <PortDuplex> <PortSpeed> <PortAu-
toNeg>
#
lappend stcProvisionList [list "10.47.20.20:1,3" "c0-e5-15-00-00-16"
"Copper" "Full" "1000" "Enable"]
lappend stcProvisionList [list "10.47.20.20:1,4" "c0-e5-15-00-00-17"
lappend stcProvisionList [list "10.47.20.20:2,9" "c0-e5-0e-00-00-34"
lappend stcProvisionList [list "10.47.20.20:2,10" "c0-e5-0e-00-00-35"
#
# Build the test configuration array
#
array set configArray [list \
\
_Checksum
{D192C04E0215086911F6909CBA9EB20E}\
\
WaDDOSConfig,AdvDevOpenConns,Descrip-
tion {Global Definitions File}\
WaDDOSConfig,globaldefs,Description
{Global Definitions File}\
WaDDOSConfig,PortableValidate_ConnsPerSec,Descrip-
tion {Global Definitions File}\
\
WaInterface,AdvDevOpenConns_inf0,Descrip-
tion {AdvDevOpenConns_inf0}\
WaInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquer-
ade,Mac0 {12}\
ade,Mac1 {22}\
WaInterface,AdvDevOpenConns_inf0,RouterSet,0,Netmask-
Bits {0}\
WaInterface,AdvDevOpenConns_inf0,Router-
Set,0,VlanId {0}\
WaInterface,AdvDevOpenConns_inf0,Sub-
nets {OpenConns_sn0}\
WaInterface,AdvDevOpenConns_inf1,Descrip-
ade,Mac0 {12}\
ade,Mac1 {22}\
WaInterface,AdvDevOpenConns_inf1,RouterSet,0,Netmask-
Bits {null}\
WaInterface,AdvDevOpenConns_inf1,Router-
Set,0,VlanId {0}\
WaInterface,AdvDevOpenConns_inf1,Sub-
nets {OpenConns_sn1}\
\
WaLoadProfile,OpenConns_lp,LoadSpecifica-
tion {Connections}\
WaLoadPro-
file,OpenConns_lp,Steps,Step,0,Height {0}\
WaLoadPro-
file,OpenConns_lp,Steps,Step,0,Label {Delay}\
WaLoadProfile,OpenConns_lp,Steps,Step,0,Steady-
Time {5}\
WaLoadPro-
WaLoadPro-
file,OpenConns_lp,Steps,Step,1,Label {Ramp
Up}\
WaLoadProfile,OpenConns_lp,Steps,Step,1,Ramp-
Time {10}\
Time {0}\
WaLoadPro-
WaLoadPro-
file,OpenConns_lp,Steps,Step,2,Label {Stair
Step}\
WaLoadPro-
file,OpenConns_lp,Steps,Step,2,Num {5}\
WaLoadProfile,OpenConns_lp,Steps,Step,2,Pat-
tern {Stair}\
WaLoadProfile,OpenConns_lp,Steps,Step,2,Ramp-
Time {1}\
Time {4}\
WaLoadPro-
WaLoadPro-
file,OpenConns_lp,Steps,Step,3,Label {Steady
State}\
WaLoadProfile,OpenConns_lp,Steps,Step,3,Pat-
tern {Stair}\
Time {40}\
WaLoadPro-
WaLoadPro-
file,OpenConns_lp,Steps,Step,4,Label {Ramp
Down}\
Time {20}\
\
WaNetworkProfile,AdvDevOpenConns,Descrip-
tion {Sample OpenConns}\
WaNetworkProfile,AdvDevOpenConns,Proxy,ProxyConnectionPersis-
tence {off}\
WaNetworkProfile,AdvDevOpenConns,TCPOptions,TCPInactivityTime-
out {70000}\
WaNetworkProfile,AdvDevOpenConns,TCPOptions,TCPPiggyback-
Get {on}\
\
WaStaticRouteTa-
ble,StaticRoutingTable_0_0 {1}\
WaStaticRouteTa-
\
WaSubnet,OpenConns_sn0,Dhcp,Option60,ChildText-
Node {}\
WaSubnet,OpenConns_sn0,DhcpPD,Number
{255}\
WaSubnet,OpenConns_sn0,DhcpPD,Timeout
{5000}\
WaSubnet,OpenConns_sn0,FlatSub-
net,Count {0}\
WaSubnet,OpenConns_sn0,IpAddressRanges,IpAddress-
Range {192.168.42.20-192.168.42.62}\
WaSubnet,OpenConns_sn0,IPsec,AuthMeth
{1}\
WaSubnet,OpenConns_sn0,IPsec,DHGroup
{1}\
WaSubnet,OpenConns_sn0,IPsec,EncAlg
{1}\
WaSubnet,OpenConns_sn0,IPsec,EspTransfor-
mId {2}\
WaSubnet,OpenConns_sn0,IPsec,HashAlg
{1}\
WaSubnet,OpenConns_sn0,IPsec,IkeRe-
tries {5}\
WaSubnet,OpenConns_sn0,IPsec,IkeTime-
out {5}\
WaSubnet,OpenConns_sn0,IPsec,IsakmpIdentifica-
tion {ISAKMPID}\
WaSubnet,OpenConns_sn0,IPsec,IsakmpIdentification-
Type {2}\
WaSub-
net,OpenConns_sn0,IPsec,Ph2DestSubnet
{192.168.42.0}\
WaSub-
net,OpenConns_sn0,IPsec,Ph2DestSubnetmask {26}\
WaSub-
net,OpenConns_sn0,IPsec,Ph2DHGroup {0}\
WaSub-
net,OpenConns_sn0,IPsec,Ph2HashAlg {1}\
WaSubnet,OpenConns_sn0,IPsec,Preshared-
Key {PRESHAREDKEY}\
WaSubnet,OpenConns_sn0,IPsec,ReKey-
Secs {0}\
WaSubnet,OpenConns_sn0,IPsec,RekeyThresh-
Secs {30}\
WaSubnet,OpenConns_sn0,IPsec,SaLdSe-
cLife {28800}\
WaSubnet,OpenConns_sn0,IPV6,AssignPre-
fix {on}\
WaSubnet,OpenConns_sn0,MacAddressRanges,MacAddress-
Range {00:00:00:00:01:01-00:00:00:00:01:FF}\
WaSubnet,OpenConns_sn0,MacMasquer-
ade,Mac0 {12}\
ade,Mac1 {22}\
WaSubnet,OpenConns_sn0,NetmaskBits
{26}\
WaSubnet,OpenConns_sn0,Network
{192.168.42.0}\
WaSubnet,OpenConns_sn0,RecvSide,NPacketsTo-
Drop {1}\
WaSubnet,OpenConns_sn0,Router,StaticRouteTa-
ble {StaticRoutingTable_0_0}\
WaSubnet,OpenConns_sn0,SendSide,NPacketsTo-
Drop {1}\
WaSubnet,OpenConns_sn0,Tunneling,LocalGwI-
pAddr {0.0.0.0}\
WaSubnet,OpenConns_sn0,Tunneling,LocalGwMac-
Addr {00:00:00:00:00:00}\
WaSubnet,OpenConns_sn0,Tunneling,Persis-
tent {on}\
WaSubnet,OpenConns_sn0,Tunneling,RemoteGwI-
pAddr {0.0.0.0}\
WaSubnet,OpenConns_sn0,UdpChecksums
{off}\
WaSubnet,OpenConns_sn0,UserPro-
file,0,Name {OpenConns_up_0}\
WaSubnet,OpenConns_sn0,UserProfile,0,Percent-
age {100}\
WaSubnet,OpenConns_sn1,Dhcp,Option60,ChildText-
Node {}\
WaSubnet,OpenConns_sn1,DhcpPD,Number
{255}\
WaSubnet,OpenConns_sn1,DhcpPD,Timeout
{5000}\
WaSubnet,OpenConns_sn1,FlatSub-
net,Count {0}\
WaSubnet,OpenConns_sn1,IpAddressRanges,IpAddress-
Range {192.168.42.65-192.168.42.126}\
WaSubnet,OpenConns_sn1,IPsec,AuthMeth
{1}\
WaSubnet,OpenConns_sn1,IPsec,DHGroup
{1}\
WaSubnet,OpenConns_sn1,IPsec,EncAlg
{1}\
WaSubnet,OpenConns_sn1,IPsec,EspTransfor-
mId {2}\
WaSubnet,OpenConns_sn1,IPsec,HashAlg
{1}\
WaSubnet,OpenConns_sn1,IPsec,IkeRe-
tries {5}\
WaSubnet,OpenConns_sn1,IPsec,IkeTime-
out {5}\
WaSubnet,OpenConns_sn1,IPsec,IsakmpIdentifica-
tion {ISAKMPID}\
WaSubnet,OpenConns_sn1,IPsec,IsakmpIdentification-
Type {2}\
WaSub-
net,OpenConns_sn1,IPsec,Ph2DestSubnet
{192.168.42.64}\
WaSub-
net,OpenConns_sn1,IPsec,Ph2DestSubnetmask {26}\
WaSub-
net,OpenConns_sn1,IPsec,Ph2DHGroup {0}\
WaSub-
net,OpenConns_sn1,IPsec,Ph2HashAlg {1}\
WaSubnet,OpenConns_sn1,IPsec,Preshared-
Key {PRESHAREDKEY}\
WaSubnet,OpenConns_sn1,IPsec,ReKey-
Secs {0}\
WaSubnet,OpenConns_sn1,IPsec,RekeyThresh-
Secs {30}\
WaSubnet,OpenConns_sn1,IPsec,SaLdSe-
cLife {28800}\
WaSubnet,OpenConns_sn1,IPV6,AssignPre-
fix {on}\
WaSubnet,OpenConns_sn1,MacAddressRanges,MacAddress-
Range {00:00:00:00:01:01-00:00:00:00:01:FF}\
ade,Mac0 {12}\
ade,Mac1 {22}\
WaSubnet,OpenConns_sn1,NetmaskBits
{26}\
WaSubnet,OpenConns_sn1,Network
{192.168.42.64}\
WaSubnet,OpenConns_sn1,RecvSide,NPacketsTo-
Drop {1}\
WaSubnet,OpenConns_sn1,Router,StaticRouteTa-
WaSubnet,OpenConns_sn1,SendSide,NPacketsTo-
Drop {1}\
WaSubnet,OpenConns_sn1,Tunneling,LocalGwI-
pAddr {0.0.0.0}\
WaSubnet,OpenConns_sn1,Tunneling,LocalGwMac-
Addr {00:00:00:00:00:00}\
WaSubnet,OpenConns_sn1,Tunneling,Persis-
tent {on}\
WaSubnet,OpenConns_sn1,Tunneling,RemoteGwI-
pAddr {0.0.0.0}\
WaSubnet,OpenConns_sn1,UdpChecksums
{off}\
WaSubnet,OpenConns_sn1,UserPro-
file,0,Name {OpenConns_up_1}\
WaSubnet,OpenConns_sn1,UserProfile,0,Percent-
age {100}\
\
WaTestProfile,Description
{Advanced Generic Device Test}\
WaTestProfile,LoadProfile
{OpenConns_lp}\
WaTestProfile,Name
{AdvDevOpenConns}\
WaTestProfile,NetworkProfile
{AdvDevOpenConns}\
WaTestProfile,Unit0,Interface,0,Name
{AdvDevOpenConns_inf0}\
WaTestProfile,Unit0,Inter-
face,0,PhysIf {0}\
WaTestProfile,Unit0,Interface,1,Name
WaTestProfile,Unit0,Inter-
face,1,PhysIf {1}\
\
WaUrlList,OpenConns_act0,0
{1 get http://192.168.42.11/?Transaction-Profile=caw1Mconnections}\
WaUrlList,OpenConns_act1,0
{1 get http://192.168.43.11/?Transaction-Profile=caw1Mconnections}\
\
WaUserProfile,OpenConns_up_0,ExtendedHttpHead-
ers {}\
WaUserProfile,OpenConns_up_0,HttpProtocol-
Level {1}\
WaUserProfile,OpenConns_up_0,MaxConnectionsPer-
CawUser {}\
WaUserProfile,OpenConns_up_0,Persis-
tence {off}\
WaUserProfile,OpenConns_up_0,SSLConfig,Cipher-
Suite,Cipher {{}}\
WaUserProfile,OpenConns_up_0,SSLConfig,Ver-
sions {{}}\
WaUserProfile,OpenConns_up_0,UrlList
{OpenConns_act0}\
WaUserProfile,OpenConns_up_0,UseCook-
ies {off}\
WaUserProfile,OpenConns_up_1,ExtendedHttpHead-
ers {}\
WaUserProfile,OpenConns_up_1,HttpProtocol-
Level {1}\
WaUserProfile,OpenConns_up_1,MaxConnectionsPer-
CawUser {}\
WaUserProfile,OpenConns_up_1,Persis-
tence {off}\
WaUserProfile,OpenConns_up_1,SSLConfig,Cipher-
Suite,Cipher {{}}\
WaUserProfile,OpenConns_up_1,SSLConfig,Ver-
sions {{}}\
WaUserProfile,OpenConns_up_1,UrlList
{OpenConns_act1}\
WaUserProfile,OpenConns_up_1,UseCook-
ies {off}\
\
WrInterface,AdvDevOpenConns_inf0,Descrip-
WrInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquer-
ade,Mac0 {12}\
ade,Mac1 {22}\
WrInterface,AdvDevOpenConns_inf0,RouterSet,0,Netmask-
Bits {0}\
WrInterface,AdvDevOpenConns_inf0,Router-
Set,0,VlanId {0}\
WrInterface,AdvDevOpenConns_inf0,Sub-
nets {echo_sn0}\
WrInterface,AdvDevOpenConns_inf1,Descrip-
ade,Mac0 {12}\
ade,Mac1 {22}\
WrInterface,AdvDevOpenConns_inf1,RouterSet,0,Netmask-
Bits {null}\
WrInterface,AdvDevOpenConns_inf1,Router-
Set,0,VlanId {0}\
WrInterface,AdvDevOpenConns_inf1,Sub-
nets {echo_sn1}\
\
WrNetworkProfile,AdvDevOpenConns,Descrip-
tion {Sample echo}\
WrNetworkProfile,AdvDevOpenConns,TCPOptions,TCPInactivityTime-
out {70000}\
WrNetworkProfile,AdvDevOpenConns,TCPOptions,TCPRe-
tries {5}\
\
WrServerProfile,HTTPServer,ApplicationProto-
col {HTTP}\
WrServerProfile,HTTPServer,Descrip-
tion {Sample echo}\
WrServerProfile,HTTPServer,HTTP,Server-
Type {Microsoft-IIS/6.0}\
WrServerProfile,HTTPServer,Port
{80}\
\
WrStaticRouteTa-
WrStaticRouteTa-
\
WrSubnet,echo_sn0,IpFrag,PacketsPerMil-
lion {1000000}\
WrSubnet,echo_sn0,IPsec,Address
{0.0.0.0}\
WrSubnet,echo_sn0,IPsec,AuthMeth
{}\
WrSubnet,echo_sn0,IPsec,DHGroup
{1}\
WrSubnet,echo_sn0,IPsec,DNS
{0.0.0.0}\
WrSubnet,echo_sn0,IPsec,DNS2
{0.0.0.0}\
WrSubnet,echo_sn0,IPsec,EncAlg
{1}\
WrSubnet,echo_sn0,IPsec,EspTransfor-
mId {2}\
WrSubnet,echo_sn0,IPsec,HashAlg
{1}\
WrSubnet,echo_sn0,IPsec,IkeRetries
{5}\
WrSubnet,echo_sn0,IPsec,IkeTimeout
{5}\
WrSubnet,echo_sn0,IPsec,IsakmpIdentifica-
tion {ISAKMPID}\
WrSubnet,echo_sn0,IPsec,Netmask
{255.255.255.0}\
WrSubnet,echo_sn0,IPsec,Ph2DHGroup
{0}\
WrSubnet,echo_sn0,IPsec,Ph2HashAlg
{1}\
WrSubnet,echo_sn0,IPsec,PresharedKey
{PRESHAREDKEY}\
WrSubnet,echo_sn0,IPsec,RekeyThresh-
Secs {30}\
WrSubnet,echo_sn0,IPsec,SaLdSecLife
{28800}\
WrSubnet,echo_sn0,IPV6,AssignPrefix
{on}\
WrSubnet,echo_sn0,MacAddressRanges,MacAddress-
Range {00:00:00:00:01:01-00:00:00:00:01:FF}\
WrSubnet,echo_sn0,MacMasquerade,Mac0
{12}\
{22}\
WrSubnet,echo_sn0,Network
{192.168.42.0}\
WrSubnet,echo_sn0,RecvSide,NPacketsTo-
Drop {1}\
WrSubnet,echo_sn0,Router,StaticRouteTa-
WrSubnet,echo_sn0,SendSide,NPacketsTo-
Drop {1}\
WrSubnet,echo_sn0,ServerProfile,0,IpAddress-
Range {192.168.42.11}\
WrSubnet,echo_sn0,ServerPro-
file,0,Name {HTTPServer}\
WrSubnet,echo_sn0,Tunneling,LocalGwI-
pAddr {0.0.0.0}\
WrSubnet,echo_sn0,Tunneling,LocalGwMac-
Addr {00:00:00:00:00:00}\
WrSubnet,echo_sn0,Tunneling,Persis-
tent {on}\
WrSubnet,echo_sn0,Tunneling,RemoteGwI-
pAddr {0.0.0.0}\
WrSubnet,echo_sn0,UdpChecksums
{off}\
WrSubnet,echo_sn0,VlanId
{1}\
WrSubnet,echo_sn1,IpFrag,PacketsPerMil-
lion {1000000}\
WrSubnet,echo_sn1,IPsec,Address
{0.0.0.0}\
WrSubnet,echo_sn1,IPsec,AuthMeth
{}\
WrSubnet,echo_sn1,IPsec,DHGroup
{1}\
WrSubnet,echo_sn1,IPsec,DNS
{0.0.0.0}\
WrSubnet,echo_sn1,IPsec,DNS2
{0.0.0.0}\
WrSubnet,echo_sn1,IPsec,EncAlg
{1}\
WrSubnet,echo_sn1,IPsec,EspTransfor-
mId {2}\
WrSubnet,echo_sn1,IPsec,HashAlg
{1}\
WrSubnet,echo_sn1,IPsec,IkeRetries
{5}\
WrSubnet,echo_sn1,IPsec,IkeTimeout
{5}\
WrSubnet,echo_sn1,IPsec,IsakmpIdentifica-
tion {ISAKMPID}\
WrSubnet,echo_sn1,IPsec,Netmask
{255.255.255.0}\
WrSubnet,echo_sn1,IPsec,Ph2DHGroup
{0}\
WrSubnet,echo_sn1,IPsec,Ph2HashAlg
{1}\
WrSubnet,echo_sn1,IPsec,PresharedKey
{PRESHAREDKEY}\
WrSubnet,echo_sn1,IPsec,RekeyThresh-
Secs {30}\
WrSubnet,echo_sn1,IPsec,SaLdSecLife
{28800}\
WrSubnet,echo_sn1,IPV6,AssignPrefix
{on}\
WrSubnet,echo_sn1,MacAddressRanges,MacAddress-
Range {00:00:00:00:01:01-00:00:00:00:01:FF}\
{12}\
{22}\
WrSubnet,echo_sn1,Network
{192.168.43.0}\
WrSubnet,echo_sn1,RecvSide,NPacketsTo-
Drop {1}\
WrSubnet,echo_sn1,Router,StaticRouteTa-
WrSubnet,echo_sn1,SendSide,NPacketsTo-
Drop {1}\
WrSubnet,echo_sn1,ServerProfile,0,IpAddress-
Range {192.168.43.11}\
WrSubnet,echo_sn1,ServerPro-
file,0,Name {HTTPServer}\
WrSubnet,echo_sn1,Tunneling,LocalGwI-
pAddr {0.0.0.0}\
WrSubnet,echo_sn1,Tunneling,LocalGwMac-
Addr {00:00:00:00:00:00}\
WrSubnet,echo_sn1,Tunneling,Persis-
tent {on}\
WrSubnet,echo_sn1,Tunneling,RemoteGwI-
pAddr {0.0.0.0}\
WrSubnet,echo_sn1,UdpChecksums
{off}\
WrSubnet,echo_sn1,VlanId
{1}\
\
WrTestProfile,Description
{Advanced Generic Device Test}\
WrTestProfile,Name
{AdvDevOpenConns}\
WrTestProfile,NetworkProfile
{AdvDevOpenConns}\
WrTestProfile,Unit0,Interface,0,Name
WrTestProfile,Unit0,Inter-
face,0,PhysIf {0}\
WrTestProfile,Unit0,Interface,1,Name
WrTestProfile,Unit0,Inter-
face,1,PhysIf {1}\
\
WrTransactionProfile,caw1Mconnections,Body-
Bytes {8}\
WrTransactionProfile,caw1Mconnections,BodyFile-
Name {Default}\
WrTransactionProfile,caw1Mconnections,BodyS-
tring {Spirent Comm 1kBytes with 60 sec delay}\
WrTransactionProfile,caw1Mconnections,BodyStringRandom-
Bytes {100}\
WrTransactionPro-
file,caw1Mconnections,DataType {2}\
WrTransactionProfile,caw1Mconnections,Descrip-
tion {60 sec delay 1k Bytes for 1Million connec-
tions}\
WrTransactionProfile,caw1Mconnections,Expires-
Header {Thu, 01 Jan 1970 00:00:17 GMT}\
WrTransactionProfile,caw1Mconnections,ExpiresHeaderPro-
gram {2}\
WrTransactionProfile,caw1Mconnections,ExtendedHttpHead-
ers {}\
WrTransactionProfile,caw1Mconnections,LastModified-
WrTransactionProfile,caw1Mconnections,LastModifiedHeaderPro-
gram {2}\
WrTransactionProfile,caw1Mconnections,LastModifiedHeaderProgra-
mEnd {Mon, 29 Jan 2001 23:59:59 GMT}\
WrTransactionProfile,caw1Mconnections,LastModifiedHeaderProgram-
Start {Mon, 01 Jan 2001 00:00:01 GMT}\
WrTransactionPro-
file,caw1Mconnections,Latency {60000}\
WrTransactionProfile,caw512k,Body-
Bytes {512000}\
WrTransactionProfile,caw512k,BodyS-
tring {Spirent Comm 512kByte response}\
WrTransactionProfile,caw512k,BodyStringRandom-
Bytes {100}\
WrTransactionProfile,caw512k,Descrip-
tion {512kByte response}\
WrTransactionProfile,caw512k,Expires-
WrTransactionProfile,caw512k,ExpiresHeaderPro-
gram {2}\
WrTransactionProfile,caw512k,ExtendedHttpHead-
ers {}\
WrTransactionProfile,caw512k,LastModified-
WrTransactionProfile,caw512k,LastModifiedHeaderPro-
gram {2}\
WrTransactionProfile,caw512k,LastModifiedHeaderProgra-
mEnd {Mon, 29 Jan 2001 23:59:59 GMT}\
WrTransactionProfile,caw512k,LastModifiedHeaderProgram-
Start {Mon, 01 Jan 2001 00:00:01 GMT}\
WrTransactionProfile,Data,AsciiTextFileLoca-
tion {./files/transactionbodycontent/Data.bin}\
WrTransactionProfile,Data,BodyBytes
{1024}\
WrTransactionProfile,Data,BodyStringRandom-
Bytes {100}\
WrTransactionProfile,Data,DataType
{1}\
WrTransactionProfile,Data,Description
{Data}\
WrTransactionProfile,Data,Expires-
WrTransactionProfile,Data,ExpiresHeaderPro-
gram {2}\
WrTransactionProfile,Data,ExtendedHttpHead-
ers {}\
WrTransactionProfile,Data,LastModified-
WrTransactionProfile,Data,LastModifiedHeaderPro-
gram {2}\
WrTransactionProfile,Data,LastModifiedHeaderProgra-
mEnd {Mon, 29 Jan 2001 23:59:59 GMT}\
WrTransactionProfile,Data,LastModifiedHeaderProgram-
Start {Mon, 01 Jan 2001 00:00:01 GMT}\
WrTransactionProfile,Default,Body-
Bytes {64}\
WrTransactionProfile,Default,BodyStringPosi-
tion {2}\
WrTransactionProfile,Default,BodyStringRandom-
Bytes {100}\
WrTransactionProfile,Default,Descrip-
tion {Default Server}\
WrTransactionProfile,Default,Expires-
WrTransactionProfile,Default,ExpiresHeaderPro-
gram {2}\
WrTransactionProfile,Default,ExtendedHttpHead-
ers {}\
WrTransactionProfile,Default,LastModified-
WrTransactionProfile,Default,LastModifiedHeaderPro-
gram {2}\
WrTransactionProfile,Default,LastModifiedHeaderProgra-
mEnd {Mon, 29 Jan 2001 23:59:59 GMT}\
WrTransactionProfile,Default,LastModifiedHeaderProgram-
Start {Mon, 01 Jan 2001 00:00:01 GMT}\
WrTransactionProfile,Delay,AsciiTextFileLoca-
tion {./files/transactionbodycontent/Delay.bin}\
WrTransactionProfile,Delay,BodyBytes
{64}\
WrTransactionProfile,Delay,BodyStringRandom-
Bytes {100}\
WrTransactionProfile,Delay,DataType
{1}\
WrTransactionProfile,Delay,Descrip-
tion {Delay}\
WrTransactionProfile,Delay,Expires-
WrTransactionProfile,Delay,ExtendedHttpHead-
ers {}\
WrTransactionProfile,Delay,LastModified-
WrTransactionProfile,Delay,LastModifiedHeaderProgra-
mEnd {Mon, 29 Jan 2001 23:59:59 GMT}\
WrTransactionProfile,Delay,LastModifiedHeaderProgram-
Start {Mon, 01 Jan 2001 00:00:01 GMT}\
WrTransactionProfile,Delay,Latency
{5000}\
]
Sample Test Script
Sample Test Script

The contents of the test.tcl script is as follows:
######################################################################
####
#
# GUI2Script Generated Test
#
######################################################################
####
#
# COMMANDER INFO
# - Originating Test Name : AdvDevOpenConns
# - Originating Project Name : Validation
#
######################################################################
####
# Script Created: 2007/08/27 11:58:19
######################################################################
####
#
# Initialization of user boolean(s)
#
set bEnableLogging 0; # Enable (1) to create a log file for enhanced
debugging
#
# Initialization of status boolean(s)
#
set bTestActive 0
#
# Define a Client callback procedure
#
proc clientStatsCallbackProc {clusterID data} {
Sample Test Script
catch {
puts "Client Attempted : $dataArray(http,attemptedTxns)"
puts "Client Successful : $dataArray(http,successfulTxns)"
puts "Client Unsuccessful : $dataArray(http,unsuccessfulTxns)"
puts "Client Aborted : $dataArray(http,abortedTxns)"
puts "\t\t\tRemaining : $dataArray(timeRemaining)"
}
puts ""
}
#
# Define a Server callback procedure
#
proc serverStatsCallbackProc {clusterID data} {
catch {
puts "Server Per second : $dataArray(tcpConn,connsPerSec)"
puts "Server Open : $dataArray(tcpConn,openConns)"
puts "Server Closed with error : $dataArray(tcpConn,closedWithEr-
ror)"
puts "Server Closed with reset : $dataArray(tcpConn,closedWith-
Reset)"
puts "Server Closed no error : $dataArray(tcpConn,closedWithNo-
Error)"
}
puts ""
}
if {[catch {
#
# Load the SPI_AV package
#
Sample Test Script

munications/Spirent TestCenter 2.10/Layer 4-7 Application/TclAPI"]
package forget SPI_AV
package require SPI_AV
#
# Initialize the API
#
#
# Add the appropriate license(s)
#
SPI_AV::AddLicense -STC 10.47.20.20
#
# Source the config file
#
source "./config.tcl"
#
# Set test directory and test id
#
set testDirectory "C:/TclAPI/2.10/Build_0059/AdvDevOpenConns"
set testId "AdvDevOpenConns"
#
# Enable logging if required
#
if {$bEnableLogging} {
SPI_AV::DebugLogFile on
}
#
# Attempt to Provision Spirent TestCenter Cards
#
puts "Attempting to provision Spirent TestCenter Ports"
Sample Test Script
if {[SPI_AV::STC::ProvisionPorts $stcProvisionList]} {
puts "Spirent TestCenter Ports SUCCESSFULLY provisioned"
} else {
puts "Problem encountered provisioning Spirent TestCenter Ports -
Aborting Test"
return -1
}
#
# Generate the test
#
puts -nonewline "Generating Test"; flush stdout
SPI_AV::ClusterController::GenerateClusteredTest configArray
$testDirectory $testId
puts " - done"
#
# Create Client Cluster
#
set clientUnits [list]
lappend clientUnits "10.47.20.20:1,2;0"
set clientClusterID [SPI_AV::ClusterController::CreateCluster
"client" "MyClientCluster" $clientUnits]
#
# Create Server Cluster
#
set serverUnits [list]
lappend serverUnits "10.47.20.20:2,5;0"
set serverClusterID [SPI_AV::ClusterController::CreateCluster
"server" "MyServerCluster" $serverUnits]
#
# Stop the cluster(s)
#
puts -nonewline "Stopping Client Cluster"; flush stdout
Sample Test Script
SPI_AV::ClusterController::StopClusteredTest $clientClusterID
SPI_AV::ClusterController::WaitForClusteredTestCompletion $client-
ClusterID
puts " - done"
puts -nonewline "Stopping Server Cluster"; flush stdout

SPI_AV::ClusterController::StopClusteredTest $serverClusterID
SPI_AV::ClusterController::WaitForClusteredTestCompletion $server-
ClusterID
puts " - done"
#
# Remove any previous copy of the test from the cluster(s)
#
puts -nonewline "Removing Test From Client Cluster"; flush stdout
SPI_AV::ClusterController::RemoveClusteredTest $clientClusterID
$testId
puts " - done"
puts -nonewline "Removing Test From Server Cluster"; flush stdout

SPI_AV::ClusterController::RemoveClusteredTest $serverClusterID
$testId
puts " - done"
#
# Upload the test to the cluster(s)
#
puts -nonewline "Uploading Test To Client Cluster"; flush stdout
SPI_AV::ClusterController::UploadClusteredTest $clientClusterID
puts " - done"
puts -nonewline "Uploading Test To Server Cluster"; flush stdout

SPI_AV::ClusterController::UploadClusteredTest $serverClusterID
puts " - done"
Sample Test Script
#
# Register a statsCallback for the cluster(s)
#
set clientStatsCallbackID [SPI_AV::ClusterController::Register-
StatsCallback $clientClusterID clientStatsCallbackProc [list "time*"
"http"]]
set serverStatsCallbackID [SPI_AV::ClusterController::Register-
StatsCallback $serverClusterID serverStatsCallbackProc [list "tcpConn"
"time*" ]]
# Status variable update

set bTestActive 1
#
# Start the test
#
puts -nonewline "Starting Server Cluster"; flush stdout
SPI_AV::ClusterController::StartClusteredTest $serverClusterID
$testId
puts " - done"
puts -nonewline "Starting Client Cluster"; flush stdout

SPI_AV::ClusterController::StartClusteredTest $clientClusterID
$testId
puts " - done"
#
# Wait for the client cluster to finish
#
puts -nonewline "Waiting For Client Cluster To Complete"; flush
stdout
SPI_AV::ClusterController::WaitForClusteredTestCompletion $client-
ClusterID
puts " - done"
Sample Test Script
#
# Stop the server cluster (and wait for it to stop)
#
puts -nonewline "Stopping Server Cluster"; flush stdout
SPI_AV::ClusterController::StopClusteredTest $serverClusterID
SPI_AV::ClusterController::WaitForClusteredTestCompletion $server-
ClusterID
puts " - done"
# Status variable update

set bTestActive 0
#
# Download test results
#
set resultsDirectory [file join $testDirectory $testId "results"]
puts -nonewline "Transferring Client Cluster Results"; flush stdout
SPI_AV::ClusterController::GetClusteredTestResults $clientClus-
terID $testId [file join $resultsDirectory]
puts " - done"
puts -nonewline "Transferring Server Cluster Results"; flush stdout

SPI_AV::ClusterController::GetClusteredTestResults $serverClus-
terID $testId [file join $resultsDirectory]
puts " - done"
} catchError]} {
puts "An exception occurred: $catchError"
puts "ErrorInfo:"
puts "$::errorInfo"
if {$bTestActive} {
catch {SPI_AV::ClusterController::AbortClusteredTest $client-
ClusterID}
catch {SPI_AV::ClusterController::AbortClusteredTest $server-
ClusterID}
}
Sample Test Script
# Stop the poller if it is alive

if [info exists port] {
catch {SPI_AV::StopSNMPPolling $port}
}
catch {SPI_AV::Dump}
}
#
# Unregister the previously registered callbacks
#
catch {SPI_AV::ClusterController::UnregisterStatsCallback $clientClus-
terID $clientStatsCallbackID}
catch {SPI_AV::ClusterController::UnregisterStatsCallback $serverClus-
terID $serverStatsCallbackID}
catch {SPI_AV::STC::CleanUp}
catch {SPI_AV::CleanUp}
puts "Done!"
Appendix C
Troubleshooting Scripts
This appendix describes some of the common problems you might encounter when
running test scripts written with the Scripting API for the Layer 4-7 Application and
includes troubleshooting tips for resolving them.
In this appendix...
• Troubleshooting Common Problems . . . . 290
Appendix C: Troubleshooting Scripts
Troubleshooting Common Problems

This section provides troubleshooting checklists to help you resolve some common
problems you may encounter when running Tcl test scripts for your device.
Check your environment

Error message: tDOM wasn’t compile for multithreading.
Check to be sure you have the correct version of ActiveTcl:
1 Open a new window. If you are using Windows, choose Run from the Start menu, and
enter CMD.
2 Check your ActiveTcl version (for example, type c:\tclshl).
3 At the Tcl prompt (%), type info patchlevel, and press Enter to see the Tcl
version you are running.
Refer to the Release Notes for the correct version of Tcl to use for the current release.
4 Type package require tdom, and press Enter. It should return 080 or higher.
5 Type package require tbcload, and press Enter. It should return 1.3 or higher.
Check your debug logs

The Scripting API for the Layer 4-7 Application, provides debug logs to help you
determine the cause of the problem. In a Windows environment, you can open the .dbg log
using WinZip.
To open a .dbg file on Linux and Solaris environments, you must use gunzip and untar.
If your SPI_AV::Dump function created a <script_name>_apidump.dbg file, you must
first rename the .dbg file with a “.gz” extension so that you can then gunzip and then untar
it to see its contents, which include the debug and event log files.
Follow these steps to unzip and untar the <script_name>_apidump.dbg file:
1 Rename the <script_name>_apidump.dbg file and change its .dbg extension to .gz as
follows: # mv <script_name>_apidump.dbg <script_name>_apidump.gz
2 Unzip the <script_name>_apidump.gz file as follows:
gunzip <script_name>_apidump.gz (resulting filename will have no extension)
3 Untar the <script_name>_apidump file to retrieve the debug and event log files:
tar xvf <script_name>_apidump
Tip: If you get an error message when generating a Tcl script from a test created in the
Layer 4-7 Application, check the log files created in the GUI2TclDebug and TestDivide
directories to help you troubleshoot the issue: Gui2Tcl_out.log, Gui2Tcl_err.log,
Divide.err, and Divide.out.
Warning: Dispatcher::startClient failed: Failed to start Client or WARNING: Dis-

patcher::startServer failed: Failed to start Server
If you see this warning, use the SPI_AV::GetLastError command against the appliance
on the side reporting the error (that is, client side appliance or server). This command will
query the appliance and return the last error it encountered, which should relate to the
current test assuming you included the SPI_AV::ClearEventLogs function as part of the
test. (SPI_AV::ClearEventLogs is automatically issued for GUI-to-Tcl generated tests).
The error message includes a description of the problem. If the error message does not
help you determine the problem, you can re-run the test and send the
<testname>_apidump.dbg file back to Spirent for further analysis. The
<testname>_apidump.dbg file is generated by the SPI_AV::Dump command.
Check the autopath, license directory, and LD_LIBRARY_PATH

Error message: SPI_AV not initialized or auto_path not set or missing library file
TclAPI functionality for Solaris/Linux is dependent on the tar and gzip commands. The
TclAPI does not call these two commands with their absolute paths; their location is
assumed to be part of the user's PATH environment variable. If that is not the case, then
you will get an error message such as ‘tar –cf test.tar .: Command not found.’
If “tar“ and “gzip” commands are not part of your PATH environment variable by default,
add their locations into your PATH environment variable. You can check if the path to
“tar“ and “gzip” commands is in your PATH variable by using the “which tar” and “which
gzip” commands. If they are already in your PATH variable, then the full path/location for
these commands will be successfully returned.
1 Define your appropriate environment variables as follows:
bash:
export LD_LIBRARY_PATH=“/<current_dir>/Spirent_TestCenter_2.xx/
Layer_4_7_Application_Solaris/STC:/<current_dir>/
Spirent_TestCenter_2.xx/Layer_4_7_Application_Solaris/TclAPI/SmartLib/
unix/solaris:$LD_LIBRARY_PATH”
If you plan to generate a portable Tcl test from the Scripting API for the Layer 4-7
Application (for example, you many want to generate a test in Windows, and then execute
it on another operating system or computer), then you must set the following additional
system environment variable on every computer on which you intend to run the test:
SPIRENT_TCLAPI_ROOT
SPIRENT_TCLAPI_LICENSEROOT
The first variable should point to the root API installation directory on the computer. The
second variable should point to a directory housing all of the licenses (valid only for
appliances) on that computer. If these two variables have been configured correctly and
valid license files exist within the license directory, the test should run successfully. If you
do not want to set these environment variables on your computer, you can manually
modify the test script to include these variables.
bash:
export SPIRENT_TCLAPI_ROOT=<current_dir>/Spirent_TestCenter_2.xx/
Layer_4_7_Application_Solaris/TclAPI
2 Add a license file for Spirent TestCenter following the API initialization function call
(SPI_AV::InitializeAPI) as follows:
SPI_AV::AddLicense -STC <Spirent TestCenter chassis IP address(es)>
Example: SPI_AV::AddLicense -STC 10.47.52.21
If the LD_LIBRARY_PATH is not defined properly, the error message will look similar to
the example shown below, which is the error message that appears when the tclet100.so
library file is missing:
couldn't load file "/thot/L4L7/Spirent_TestCenter_2.xx/
Layer_4_7_Application_Solaris/TclAPI/SmartLib/unix/solaris/
tclet100.so": ld.so.1: tclsh8.4: fatal: libetsmb.so: open failed: No
such file or directory
The error message above means the path to the library file is either not known or not part
of the LD_LIBRARY_PATH variable, so the file is considered to be missing.
The same above change needs to be done for the “export LD_LIBRARY_PATH=…“
command here since it only shows path for STC directory which also needs to include the
…/SmartLib/unix/solaris (or linux) path as shown above.
Check Spirent TestCenter provisioning

The Spirent TestCenter provisioning list requires six parameters for each port and in the
following order: portId, portMac, portMedia, portDuplex, portSpeed and portAutoNeg).
The order of parameter values is very important, so skipping a parameter value or
changing the order of these values will give you error messages and prevent your test from
running.
Example:
lappend stcProvisionList [list "10.47.52.21:3,1" "a4-b4-89-00-00-19"
lappend stcProvisionList [list "10.47.52.21:3,2" "a4-b4-89-00-00-1d"
Each Spirent TestCenter card can have up to six CPUs on it, and each CPU can control up
to two ports. Also, Spirent TestCenter is 1-based, so you cannot assign any ports with 0.
Appendix D
ESD Requirements
Spirent Communications manufactures and sells products that require industry standard
precautions to protect against damage from electrostatic discharge (ESD). This document
explains the proper process for handling and storing electrostatic discharge sensitive
(ESDS) devices, assemblies, and equipment.
The requirements presented in this document comply with the EIA Standard, ANSI/ESD
S20.20-1999: Development of an Electrostatic Discharge Control Program, and apply to
anyone who handles equipment that is sensitive to electrostatic discharge. Such equipment
includes, but it not limited to:
• All electronic assemblies manufactured by Spirent Communications
• Discrete and integrated circuit semiconductors
• Hybrid microcircuits
• Thin film passive devices
• Memory modules
Caution: Failure to comply with the requirements explained in this document poses risks
! to the performance of ESDS devices, as well as to your investment in the equipment.
General Equipment Handling

Whenever you handle a piece of ESDS equipment, you must be properly grounded to
avoid harming the equipment. Also, when transporting the equipment, it must be packaged
properly. Follow the requirements below to help ensure equipment protection.
• Wrist straps must be worn by any person handling the equipment to provide normal
grounding.
• The use of foot straps is encouraged to supplement normal grounding. If foot straps are
used exclusively, two straps (one on each foot) should be used. Note that foot straps
are only applicable in environments that use ESD flooring and/or floor mats.
• Hold ESDS equipment by the edges only; do not touch the electronic components or
gold connectors.
• When transporting equipment between ESD protected work areas, the equipment must
be contained in ESD protective packaging. Equipment that is received in ESD

Appendix D: ESD Requirements
protective packaging must be opened either by a person who is properly grounded or at

an ESD protected workstation.
• Any racks or carts used for the temporary storage or transport of ESDS equipment
must be grounded either by drag chains or through direct connection to earth ground.
Loose parts that are not protected by ESD-safe packaging must not be transported on
carts.
Workstation Preparation
The ideal setup for working with ESDS equipment is a workstation designed specifically
for that purpose. Figure D-1 illustrates an ESD protected workstation. Please follow the
requirements listed below to prepare a proper ESD protected workstation.
• The ESD Ground must be the equipment earth ground. Equipment earth ground is the
electrical ground (green) wire at the receptacles.
• An ESD protected workstation consists of a table or workbench with a static
dissipative surface or mat that is connected to earth ground. A resistor in the grounding
wire is optional, providing that surface resistance to ground is ≥ 105 to
≤ 109 Ω.
• The workstation must provide for the connection of a wrist strap. The wrist strap must
contain a current limiting resistor with a value from ≥ 250K Ω to ≤ 10M Ω.
• ESD protective flooring or floor mats are required when floor-grounding devices (foot
straps/footwear) are used or when it is necessary to move in between ESD protected
workstations when handling ESDS equipment.
ESD protective
Optional resistor surface or mat
Wrist strap
ESD protective
floor mat (optional)
Figure D-1. ESD Protected Workstation
Note: The equipment needed for proper grounding is available in ESD service kits, such
as the ESD Field Service Kit available from Spirent Communications (P/N 170-1800).
Additional information on ESD can be found on the following website:
http://www.esda.org/aboutesd.html

Appendix E
Fiber Optic Cleaning Guidelines
Spirent Communications manufactures and sells products that contain fiber optic
components, including fiber optic transmitters and receivers. These components are
extremely susceptible to contamination by particles of dirt or dust, which can obstruct the
optic path and cause performance degradation. To ensure optimum product performance,
it is important that all optics and connector ferrules be kept clean.
This document presents guidelines for maintaining clean fiber optic components. Spirent
Communications recommends that these guidelines be followed very closely.
Caution: • Failure to comply with the guidelines explained in this document poses
! risks to the performance of fiber optic-based devices, as well as to your
investment in the equipment.
• Whenever you handle a piece of equipment that contains fiber optic
components, you must be properly grounded to avoid harming the
equipment. See the Appendix in this document titled ESD Requirements
for more details on ESD.
Cleaning Guidelines
To ensure the cleanliness of fiber optic components, follow the guidelines below:
• Use fiber patch cords (or connectors if you terminate your own fiber) only from a
reputable supplier. Low-quality components can cause many hard-to-diagnose
problems during an installation.
• Dust caps are typically installed on fiber optic components to ensure factory-clean
optical devices. These protective caps should not be removed until the moment of
connecting the fiber cable to the device. Ensure that the fiber is properly terminated,
polished, and free of any dust or dirt. Also make sure that the location of installation is
as free of dust and dirt as possible.
• Should it be necessary to disconnect the fiber device, reinstall the protective dust caps.
• If you suspect that the optics have been contaminated, alternate between blasting with
clean, dry, compressed air and flushing with methanol to remove particles of dirt.

Index
A UnregisterStatsCallback 188
AbortClusteredTest function 183 UploadClusteredTest 189
AddLicense function 201 ValidateClusteredTest 189
AddUnitToCluster function 183 WaitForClusteredTestCompletion 190
AdjustLoad function 201 Interactive Testing
Avalanche appliance software ClearEventLog 213
upgrading 18 DebugLogFile 214
GenerateTest 214
C GetTestResults 215
cleaning guidelines, fiber optics 295 GetTestStage 216
CleanUp function 194, 197, 203 IsTestRunning 216
ClearEventLog function 213 RegisterStatsCallback 216
ClearEventLogs function (cluster) 184 RemoveTest 218
Clustered Parameters 177 StartSNMPPolling 218
configuration array StartTest 219
modifying 24, 25, 26 StopSNMPPolling 219
CreateCluster function 184 StopTest 220
UnregisterStatsCallback 220
D UploadTest 221
DebugLogFile function 214 ValidateTest 221
DeleteCluster function 184 Version 222
DownloadCookies function 203 WaitForTestCompletion 222
Dump function 203 Query
GetParameter 191
E GetProfileName 191
equipment handling GetProfileParameters 192
ESD service kits 294 GetProfileType 192
preparing your workstation 294 GetValidProfileType 193
ESD requirements 293 SetParameter 193
Spirent TestCenter
F CleanUp 194, 197
ProvisionPorts 195, 198
functions 191, 194, 197, 200, 212
Standard
Clustered
AddLicense 201
AbortClusteredTest 183
AdjustLoad 201
AddUnitToCluste 183
CleanUp 203
ClearEventLogs (cluster) 184
DownloadCookies 203
CreateCluster 184
Dump 203
DeleteCluster 184
GetAdminConfig 204
GenerateClusteredTest 185
GetEventLog 205
GetClusteredTestResults 185
GetHostList 206
IsClusteredTestRunning 186
GetInterfaceList 207
RegisterStatsCallback (cluster) 186
GetLastError 208
RemoveClusteredTest 187
GetNumInterfaces 208
RemoveUnitFromCluster 187
GetRealTimeStats 208
StartClusteredTest 188
GetStatus 209
StopClusteredTest 188
Index
InitializeAPI 210 R
Reboot 210 Reboot function 210
RegisterStatsCallback function 216
G RegisterStatsCallback function (cluster) 186
GenerateClusteredTest function 185 RemoveClusteredTest function 187
GenerateTest function 214 RemoveTest function 218
GetAdminConfig function 204 RemoveUnitFromCluster function 187
GetClusteredTestResults function 185 requirements
GetEventLog function 205 electrostatic discharge 293
GetHostList function 206
GetInterfaceList function 207 S
GetLastError function 208 sample test script
GetNumInterfaces function 208 modifying 28
GetParameter function 191 Scripting API
GetProfileName function 191 configuring a test 20
GetProfileParameters function 192 installing 15
GetProfileType function 192 running a test 20
GetRealTimeStats function 208 supported functionality 17
GetStatus function 209 scripts
GetTestResults function 215 debugging 38
GetTestStage function 216 modifying 28
GetValidProfileType function 193 Server Content Upload Parameters 176
Global test profile 178 server profile 139
SetParameter function 193
H Spirent TestCenter
hardware requirements chassis support 9
Spirent TestCenter chassis 9 hardware requirements 9
modifying a configuration array for 26
I test configuration array 26
InitializeAPI function 210 Spirent TestCenter functions 194, 197
installation Standard functions 200
hardware 9 StartClusteredTest function 188
Interactive Testing functions 212 StartSNMPPolling function 218
IsClusteredTestRunning function 186 StartTest function 219
IsTestRunning function 216 statistics
displaying 37
J StopClusteredTest function 188
Java StopSNMPPolling function 219
installing 14 StopTest function 220
M T
messages test configuration array
printing results 37 Avalanche/Client parameters 41, 178
Clustered parameters 177
N clustered parameters 177
notation conventions Global 178
reference manual 8 modifying 24, 25, 26
profile entry format 40
P rReflector/Server parameters 119
profile samples 21
server 139 test profile parameters 177
user 75 Transaction Profile 167
ProvisionPorts function 195, 198 WaCapRepEth 111
WaCapRepTCP 106
Q WaCapRepUDP 109
WaCertificate 117, 176
Query functions 191
WaContent 114
WaDDOSConfig 95
Index
WaFormDatabase 114 WaNetworkProfile 52

WaHostFile 117 WaPPPGroupProfile 92
WaHttpContent 115, 116 WaPPPoEGroupParams 95
WaInterface 56 WaStaticRouteTable 89
WaLoadProfile 45 WaSubnet 60
WaNetworkProfile 52 WaTelnetProfile 90
WaPPPGroupProfile 92 WaTestProfile 42
WaPPPoEGroupParams 95 WaUrlList 88
WaStaticRouteTable 89 WaUserProfile 75
WaSubnet 60 workstation preparation 294
WaTelnetProfile 90 WrContent 176
WaTestProfile 42 WrInterface 123
WaUrlList 88 WrNetworkProfile 121
WaUserProfile 75 WrServerProfile 139
WrContent 176 WrStaticRouteTable 139
WrInterface 123 WrSubnet 125
WrNetworkProfile 121 WrTestProfile 120
WrServerProfile 139
WrStaticRouteTable 139
WrSubnet 125
WrTestProfile 120
test results
collecting 37
printing 37
test scripts
debugging 38
samples 21
tests
samples included with API 24
Transaction Profile 167
U
UnregisterStatsCallback function 220
UnregisterStatsCallback function (cluster) 188
Upgrading appliance software 18
UploadClusteredTest function 189
UploadTest function 221
user profile 75
V
ValidateClusteredTest function 189
ValidateTest function 221
Version function 222
W
WaCapRepEth 111
WaCapRepTCP 106
WaCapRepUDP 109
WaCertificate 117, 176
WaContent 114
WaDDOSConfig 95
WaFormDatabase 114
WaHostFile 117
WaHttpContent 115, 116
WaInterface 56
WaitForClusteredTestCompletion function 190
WaitForTestCompletion function 222
WaLoadProfile 45

L4 7 Scripting API

Uploaded by

Copyright:

Available Formats

L4 7 Scripting API

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

L4 7 Scripting API

Uploaded by

Copyright:

Available Formats

Reference Manual

Scripting API for the

P/N 71-003808 REV A

Chapter 2: Using the Scripting API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 3: Test Configuration Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Scripting API for the Layer 4-7 Application Reference Manual | 3

Chapter 4: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Appendix A: Statistics Message Indices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

4 | Scripting API for the Layer 4-7 Application Reference Manual

Appendix B: Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Appendix C: Troubleshooting Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Appendix D: ESD Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Appendix E: Fiber Optic Cleaning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Scripting API for the Layer 4-7 Application Reference Manual | 5

• Hardware Handling/Cleaning Practices . . . . 10

Scripting API for the Layer 4-7 Application Reference Manual | 7

Notation Example Meaning and Use

Courier typeface WaTestProfile Indicates elements such as names of parameters,

Square brackets [description] Indicates an optional parameter. Do not enter the

Curly brackets {<attackname1> Indicates a Tcl list.

Backslash \ Indicates that the command continues to the next line.

8 | Scripting API for the Layer 4-7 Application Reference Manual

Note: The Layer 4-7 documentation is located in your installation’s documentation

Scripting API for the Layer 4-7 Application Reference Manual | 9

Hardware Handling/Cleaning Practices

10 | Scripting API for the Layer 4-7 Application Reference Manual

Europe, Africa, Middle East

Scripting API for the Layer 4-7 Application Reference Manual | 11

• Installing the Scripting API . . . . 15

• Upgrading Appliance Software . . . . 18

• Sample Test Configuration Arrays and Test Scripts . . . . 21

Scripting API for the Layer 4-7 Application Reference Manual | 13

Scripting API Overview

14 | Scripting API for the Layer 4-7 Application Reference Manual

Installing the Scripting API

To Install the Scripting API Software on Windows XP

To Install the Scripting API Software on Linux or Solaris

Scripting API for the Layer 4-7 Application Reference Manual | 15

16 | Scripting API for the Layer 4-7 Application Reference Manual

Current Supported Functionality

Scripting API for the Layer 4-7 Application Reference Manual | 17

Upgrading Appliance Software

To upgrade appliance software

1 Open a console window in your Linux or Solaris host machine.

18 | Scripting API for the Layer 4-7 Application Reference Manual

The following example illustrates this process:

Scripting API for the Layer 4-7 Application Reference Manual | 19

To modify/configure and run an existing client/server test:

1 Check license and network information.

20 | Scripting API for the Layer 4-7 Application Reference Manual

Sample Test Configuration Arrays and Test Scripts

Generate Tcl Scripts from the Layer 4-7 Application

Setting a Custom Username

Scripting API for the Layer 4-7 Application Reference Manual | 21

Checksum in Sample Configuration Arrays

22 | Scripting API for the Layer 4-7 Application Reference Manual

• Printing and Collecting Test Results . . . . 37

• Debugging a Test Script . . . . 38

Scripting API for the Layer 4-7 Application Reference Manual | 23

To configure and run a client/server test: