L4 7 Scripting API

P/N 71-003808 REV A

Reference Manual

Scripting API for the Layer 4-7 Application January 2008

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 WarrantySpirent 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Hardware Handling/Cleaning Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10How to Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Scripting API Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Installing Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Installing the Scripting API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

On Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15On Linux or Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Upgrading Appliance Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Sample Test Configuration Arrays and Test Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Generate Tcl Scripts from the Layer 4-7 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Setting a Custom Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Checksum in Sample Configuration Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 2: Using the Scripting API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Configuring Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Modifying a Test Configuration Array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Modifying a Sample Test Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Executing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Monitoring Results on the Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Validating Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Printing and Collecting Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Printing Results to a Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Debugging a Test Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter 3: Test Configuration Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Format of a Profile Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Client Test Configuration Array Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Server Test Configuration Array Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Clustered Test Configuration Array Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Test Profile Interface Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Global Test Configuration Array Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

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

Contents

Chapter 4: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Clustered Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

General Terminology for Clustered Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Query Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Spirent TestCenter Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Appliance Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Standard Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Interactive Testing Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Appendix A: Statistics Message Indices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Client Statistics Message Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Filters to Use for Client Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

TCP Capture-Replay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226UDP Capture-Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226DDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Load Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Simulated Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239TCPState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245MM4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Server Statistics Message Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Filters to Use for Server Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

TCP Capture-Replay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250UDP Capture-Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

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

Contents

TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256TCP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257TCP State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260MM4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Appendix B: Sample Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Sample Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Sample Test Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Appendix C: Troubleshooting Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Troubleshooting Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Check your environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Check your debug logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Check the autopath, license directory, and LD_LIBRARY_PATH. . . . . . . . . . . . . . . . 291Check Spirent TestCenter provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Appendix D: ESD Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293General Equipment Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Workstation Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Appendix E: Fiber Optic Cleaning Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Cleaning 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 GuideIntroduction

IntroductionThis 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 ConventionsThe 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> <attackname2>}

Indicates a Tcl list.

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 function for more information.

Indicates a cross-reference. You can click on the cross-reference to jump to the description of that function or parameter.


About this GuideRelated Documentation

Related DocumentationSee 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 GuideHardware Handling/Cleaning Practices

Hardware Handling/Cleaning PracticesSpirent 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 GuideHow to Contact Us

How to Contact UsTo 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

E-mail: [email protected] 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

E-mail: [email protected] 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


mailto:[email protected]

http://support.spirentcom.com




http://support.spirentcom.com.cn


http://support.spirentcom.com.cn

http://www.spirentcom.com

http://www.spirentcom.com.cn



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: IntroductionScripting API Overview

Scripting API OverviewThe 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_HOMEbash: export JAVA_HOME=“<Java_Install_Dir>”


ftp://ftp.activestate.com/ActiveTcl/Linux/8.4.8/

ftp://ftp.activestate.com/ActiveTcl/Solaris/8.4.8

ftp://ftp.activestate.com/ActiveTcl/Windows/8.4.8

Chapter 1: IntroductionInstalling 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.

Installing the Scripting APIYou 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.



Chapter 1: IntroductionInstalling the Scripting API

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)


Chapter 1: IntroductionSupported 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 ConfigurationsThis 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.


Chapter 1: IntroductionUpgrading Appliance Software

Upgrading Appliance SoftwareTo 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


Chapter 1: IntroductionUpgrading Appliance Software

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


Chapter 1: IntroductionGetting Started

Getting StartedBefore 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.”



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>



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 APIConfiguring 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.



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.



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. 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. However, you must modify the network address subnet that you want to represent for 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.



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"] lappend stcProvisionList [list "10.47.52.21:3,2" \ "a4-b4-89-00-00-1d" "Copper" "Full" "100" "Enable"] lappend stcProvisionList [list "10.47.52.21:4,1" \ "a4-b4-89-00-00-21" "Copper" "Full" "100" "Enable"] lappend stcProvisionList [list "10.47.52.21:4,2" \ "a4-b4-89-00-00-26" "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): lappend stcProvisionList [list "10.47.52.21:5,1" \ "a4-b4-89-00-00-31" "Copper" "Full" "100" "Enable"] lappend stcProvisionList [list "10.47.52.21:5,2" \ "a4-b4-89-00-00-36" "Copper" "Full" "100" "Enable"]

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. 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,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. 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. However, you must modify the network address subnet that you want to represent for 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



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: 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 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 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



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.


Chapter 2: Using the Scripting APIExecuting Scripts

Executing ScriptsBefore 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.



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)"



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


















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



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






Chapter 2: Using the Scripting APIValidating Scripts

Validating ScriptsYou 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).


Chapter 2: Using the Scripting APIPrinting and Collecting Test Results

Printing and Collecting Test ResultsYou 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.


Chapter 2: Using the Scripting APIDebugging a Test Script

Debugging a Test ScriptIf 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 ArrayFormat 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.


Chapter 3: Test Configuration ArrayClient Test Configuration Array Parameters

Client Test Configuration Array ParametersThis 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 | offEnables 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 | offEnables 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 | offEnable if you want only 4XX and 5XX HTTP error codes and content validation failures reported. The default is on.

• UserLoadEnabled yes | noEnable 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>

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <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 = Bandwidth1 = Connections2 = Connections/second3 = SimUsers4 = SimUsers/second5 = Transactions6 = Transactions/second7 = BodyBytes10 = SimUsers/hour11 = Connections/hour12 = Transactions/hourEach 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>

Specifies the parameter as one of the following values: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>


Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <NetworkProfileName>

Specifies the name for this Network Profile on the target device. This name is used to reference this profile from within other profiles.

• <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 lifetimeThis 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

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <InterfaceProfile Name>

Specifies the name for this Interface Profile on the target device. This name is used to reference this profile from within other profiles.

• <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>

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values: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 adhere to the following syntax: WaInterface,<InterfaceProfileName>,RouterSet,<RouterCon-figNumber>,<RouterSet Parameter> <value>

◊ <RouterConfigNumber>

Iterates with each new router definition from 0 onwards.◊ <RouterSet parameter><value>

Specifies the parameter as one of the following values:o IpAddress X.X.X.X

Specify a virtual router IP address. o NetmaskBits <integer>

Specify the virtual router’s netmask.o StaticRouteTable <StaticRouteFilename>

Specify the name of the XML file containing the static routing table. Use 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>

Iterates with each new router definition from 0 onwards.◊ <MAC parameter> <value>

Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <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:• Description {<description>}

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-tion array should adhere to the following syntax: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 adhere to the following syntax: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 50000. The default is 0.

◊ 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.


If you specified 1 or 2 for the DelayVarianceMethod, then this parameter specifies the end of the delay variances. The default is 0.

• RecvSide

Subnet profile RecvSide attributes within the test configuration array should adhere to the following syntax: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



If you specified 1 or 2 for the DelayVarianceMethod, then this parameter specifies the start of the delay variances. The default is 0.


If you specified 1 or 2 for the DelayVarianceMethod, then this parameter 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

Enable or disable VLAN tagging. The default is 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 to the following syntax: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 should adhere to the following syntax:WaSubnet,<SubnetProfileName>,MacMasquerade, <MAC Parameter> <value>

◊ Enabled on | off

Enable or disable MAC masquerading. The default is 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 adhere to the following syntax: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>

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values:o StaticRouteTable <StaticRouteFilename>

Specify the name of the XML file containing the static routing table.• MacAddressRanges

Subnet profile MacAddressRanges attributes within the test configuration array should adhere to the following syntax:WaSubnet,<SubnetProfileName>,MacAddressRanges,<Ranges Parameter> <value>

Note: You can specify only one MAC address range.

◊ <Ranges Parameter> <value>

Specifies the parameter as one of the following values: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 should adhere to the following syntax:WaSubnet,<SubnetProfileName>,IPSec,<IPSec Parameter><value>



◊ <IPSec Parameter> <value>


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.∇ AES-256: AES with a 256-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)∇ MODP-1024 (group 2)∇ MODP-1536 (group 5)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)∇ MODP-768 (group 1)∇ MODP-1024 (group 2)∇ MODP-1536 (group 5)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 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.∇ ESP-AES-256: AES with a 256-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,


∇ SHA-1: The Secure Hash Algorithm version one, part of the U.S. Digital Signature Standard (DSS). This algorithm is considered very 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 adhere to the following syntax:WaSubnet,<SubnetProfileName>,Tunneling,<Tunneling Parame-ter> <value>

◊ <Tunneling Parameter> <value>

Specifies the parameter as one of the following values: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 to the following syntax: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>

Specifies the parameter as one of the following values: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.

• ForcedPathMTUSubnet 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>


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.

• DHCPThe 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 to the following syntax:WaSubnet,<SubnetProfileName>,Dhcp,<Dhcp Parameter><value>

◊ <Dhcp Parameter> <value>


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.

• IPV6Use the IPV6 subnet profile when configuring an IPv6 subnet. Subnet profile DHCP attributes within the test configuration array should adhere to the following syntax:WaSubnet,<SubnetProfileName>,IPV6,<IPV6 Parameter><value>

◊ <IPV6 Parameter> <value>

Specifies the parameter as one of the following values: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 | offEnable 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>

Parameters The input parameters and their values are described below:• <UserProfileName>

Specify the name for this User Profile on the target device. This name is used to reference this profile from within other profiles.

• <Parameter> <value>

Specify one of the following:• Description {<description>}

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 adhere to the following syntax:WaUserProfile,<UserProfileName>,SSLConfig, <SSLParameter> <value>

◊ <Parameter><value>

Specify one of the following: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 checking1 – Valid certificate optional2 – Valid certificate mandatoryThe default is 0.

o CipherSuite

SSLConfig profile ciphersuite attributes within the test configuration array should adhere to the following syntax: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 to the following syntax: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 adhere to the following syntax: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 Plugin2—Cisco Host Plugin3—Cisco Anti-Virus Plugin4—Cisco Firewall Plugin5—Cisco Host Intrusion Protection Service (HIPS) Plugin32768-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—Cisco311—Microsoft0-99999—Other vendor IDs (excluding 9 and 311)



∇ Attribute

NacProfile Attribute parameters within the test configuration array should adhere to the following syntax: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 = String2 = UInt323 = MAC4 = IPv45 = IPv66 = Binary7 = Date MM/DD/YYYY HH:MM:SS8 = Version X.X.X.XThe 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 92in 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 [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 adhere to the following syntax: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 should adhere to the following syntax: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 = String2 = UInt323 = MAC4 = IPv45 = IPv66 = MTU7 = BinaryThe 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}

Parameters The input parameters and their values are described below:• <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>

Parameters The input parameters and their values are described below:• <StaticRouteFilename>

Name of the static routing XML configuration file that will be created.• <RouteNumber>

Iterates with each new routing table entry from 0 onwards.




Specifies the parameter as one of the following values:• Network <X.X.X.X>

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>

Parameters The input parameters and their values are described below:• <TelnetProfileName>

Specify the name for this Telnet Profile on the target device. This name is used to reference this profile from within other profiles.


Specifies the parameter as one of the following values:• 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 characterCR – Carriage ReturnCR/LF – Carriage Return and Line FeedThe 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 should adhere to the following syntax: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>

Specifies the parameter as one of the following values: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 array should adhere to the following syntax:WaTelnetProfile,<TelnetProfileName>,Telnet,ClientCommand, <Client Command Entry Number>,<Client Command Parameter> <value>

◊ <Client Command Entry Number>

Iterates with each new Command definition within the current <TelnetProfileName> from 0 onwards.



◊ <Client Command Parameter> <value>

Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <PPPProfileName>

Specify the name for this PPP Profile on the target device. This name is used to reference this profile from within other profiles.




Specifies the parameter as one of the following values:• 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 performedPAP – 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 adhere to the following syntax:WaPPPGroupParams,<WaPPPGroupProfileName>, WildcardParams,<Wildcard parameter><value>

◊ <Wildcard parameter> <value)

Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <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>

Specifies the parameter as one of the following values:• 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>



Parameters The input parameters and their values are described below:• <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.


Specifies one of the following:• 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 devicesArp Flood attack profile entries within the test configuration array should adhere to the following syntax:WaDDOSAttack,<TestFileName>,ARPFlood, <ARPFlood Parameter> <value>

◊ <ARPFlood Parameter> <value>

Specifies the parameter as one of the following values: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 adhere to the following syntax:WaDDOSAttack,<TestFileName>,EvasiveUDP, <EvasiveUDP Parameter> <value>

◊ <EvasiveUDP Parameter> <value>





The packet generation rate in packets per second. The 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.o LocalStartDelay <integer>

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>





The packet generation rate in packets per second. The default is 1000.o TCPDestPort <integer>

The TCP port number for both the source and destination. The default is 80.

o LocalStartDelay <integer>


• 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 adhere to the following syntax:WaDDOSAttack,<TestFileName>,PingOfDeath,<POD Parameter> <value>



◊ <POD Parameter> <value>





The packet generation rate in packets per second. The default is 1000.o LocalStartDelay <integer>


• 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 to the following syntax:WaDDOSAttack,<TestFileName>,PingSweep, <PingSweep Parameter> <value>

◊ <PingSweep Parameter> <value>




o PacketRate 1000 <integer>

The packet generation rate in packets per second. The default is 1000.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 should adhere to the following syntax:WaDDOSAttack,<TestFileName>,RandomUnreachableHost, <RUH Parameter> <value>

◊ <RUH Parameter> <value>







• 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 to the following syntax:WaDDOSAttack,<TestFileName>,ResetFlood, <ResetFlood Parameter> <value>

◊ <ResetFlood Parameter> <value>





The packet generation rate in packets per second. The default is 1000.o TCPSourcePort <integer>

The TCP port number for the source. The default is 1024.o TCPDestPort <integer>

The TCP port number for the destination. The default is 80.



o LocalStartDelay <integer>


• 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>




o PacketRate 1000 <integer>

The packet generation rate in packets per second. The default is 1000.o LocalStartDelay 0 <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 to the following syntax:WaDDOSAttack,<TestFileName>,SynFlood, <SynFlood Parameter> <value>

◊ <SynFlood Parameter> <value>


The number of times to repeat the attack sequence. The default is 120.



o PacketsToGenerate <integer>

The number of packets to generate each attack sequence. The default is 1000.



The TCP header source port number. The default is 1024.o TCPDestPort <integer>

The TCP header destination port number. The default is 80.o LocalStartDelay <integer>


• 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 resources (that is, system memory) of target networks and network devices.TCP Port Scan attack profile entries within the test configuration array should adhere to the following syntax:WaDDOSAttack,<TestFileName>,TCPPortScan, <TCPPS Parameter> <value>

◊ <TCPPS Parameter> <value>

Specifies the parameter as one of the following values: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.o PacketRate <integer>


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.o LocalStartDelay <integer>




• 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>






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.o LocalStartDelay <integer>


• UDP Flood Profile ParametersA 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 to the following syntax:WaDDOSConfig,<TestFileName>,UDPFlood,<UDPFlood Parame-ter> <value>

◊ <UDPFlood Parameter> <value>


The number of times to repeat the attack sequence. The default is 200.



o PacketsToGenerate <integer>




The UDP header source port number. The default is 1024.o UDPDestPort <integer>

The UDP header destination port number. The default is 512.o LocalStartDelay <integer>


• 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 resources (that is, system memory) of target networks and network devices.UDP Port Scan attack profile entries within the test configuration array should adhere to the following syntax:WaDDOSAttack,<TestFileName>,UDPPortScan, <UDPPS Parameter> <value>

◊ <UDPPS Parameter> <value>

Specifies the parameter as one of the following values: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.o PacketRate <integer>


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.o LocalStartDelay 0 <integer>




• 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 adhere to the following syntax:WaDDOSAttack,<TestFileName>,UnreachableHost, <UH Parameter> <value>

◊ <UH Parameter> <value>





The packet generation rate in packets per second. The default is 1000.o UnreachableHostAddress <XX.XX.XX.XX>

The IP address of the unreachable host. The default is 10.0.0.1. o LocalStartDelay <integer>


• 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 to the following syntax:WaDDOSAttack,<TestFileName>,XMasTree, <XMasTree Parameter> <value>

◊ <XMasTree Parameter> <value>









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>

Parameters The input parameters and their values are described below:• <CapRepProfileName>

The name for this Capture Replay Profile on the target device. This name is used to reference this profile from within other profiles.

• <ActionNumber>

Integer value starting at 0 iterating with each individual action.• <Parameter> <value>

Specifies the parameter as one of the following values:• 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



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

Table 3-1. Capture Replay Action Type List (continued)

Action Type Minimum and Maximum Value



Syntax2 WaCapRepTCP,<CapRepProfileName>,<CapRep Parameter> <value>




Specifies the parameter as one of the following values:• 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>

Integer value starting at 0 iterating with each individual action.


Specifies one of the following:• Type <action_type>

The type of capture replay action required. See Table 3-1 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 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 page 107, for a list of acceptable action types.

Syntax2 WaCapRepUDP,<CapRepProfileName>,<CapRep Parameter> <value>








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>

Integer value starting at 0 iterating with each individual action.


Specifies one of the following:• Type <action_type>


• 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 hexadeci-mal code. For example, line feed is escaped as %0D, backspace is escaped as %08, and so on

• Min <integer>


• Max <integer>


• 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>









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>

Parameters The input parameters and their values are described below:• <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>

The input parameters and their values are described below:• 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>

The input parameters and their values are described below:• <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>

The input parameters and their values are described below:• 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>

The input parameters and their values are described below:• <Entry Index>

An iterative index starting at 0, incrementing with every subsequent IP and Name pairing.

• <HostFile Parameter> <value>

Specifies one of the following:◊ 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>

The input parameters and their values are described below:• <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>



The input parameters and their values are described below:• <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}


Chapter 3: Test Configuration ArrayServer Test Configuration Array Parameters

Server Test Configuration Array ParametersThis 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>


Specifies the parameter as one of the following values:• Description {<description>}

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>

Specifies the parameter as one of the following values: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 | offEnables 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 | offEnables 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 | offEnable 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>

Parameters The input parameters and their values are described below:• <NetworkProfileName>

The name for this Network Profile on the server. This name is used to reference this profile from within other profiles.





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>

Specifies the parameter as one of the following values: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>

Parameters The input parameters and their values are described below:• <InterfaceProfileName>

The name for this Interface Profile on the server. This name is used to reference this profile from within other profiles.

• <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 to the following syntax:WrInterface,<InterfaceProfileName>,Router, <Router Parameter> <value>


Specifies one of the following: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.

o NetmaskBits <integer>

Enter the virtual router’s netmask. o StaticRouteTable <StaticRouteFilename>

Specify the name of the XML file containing the static routing table. Use 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 adhere to the following syntax: WrInterface,<InterfaceProfileName>,RouterSet,<RouterCon-figNumber>,<RouterSet Parameter> <value>

◊ <RouterConfigNumber>

Iterates with each new router definition from 0 onwards.◊ <RouterSet parameter><value>

Specifies the parameter as one of the following values:o IpAddress X.X.X.X

Specify a virtual router IP address. o NetmaskBits <integer>

Specify the virtual router’s netmask.



o StaticRouteTable <StaticRouteFilename>

Specify the name of the XML file containing the static routing table. Use 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: WrInterface,<InterfaceProfileName>,RouterSet,<RouterCon-figNum>,MacMasquerade,<MAC Parameter><value>

◊ <RouterConfigNum>

Iterates with each new router definition from 0 onwards..◊ <MAC parameter> <value>


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.

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>

Parameters The input parameters and their values are described below:• <SubnetProfileName>

The name of the subnet profile to configure.• <Parameter> <value>




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. • Network <X.X.X.X>

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 adhere to the following syntax:WrSubnet,<SubnetProfileName>,SendSide, <SendSide Parameter> <value>

◊ <SendSide Parameter> <value>

Specifies one of the following: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>


o NPacketsToDrop <integer>


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


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.


If DelayVariationMethod is specified as 1 or 2, then use this parameter to specify the end of the delay variances. The default is 0.

• RecvSide

Subnet profile RecvSide attributes within the test configuration array should adhere to the following syntax:WrSubnet,<SubnetProfileName>,RecvSide, <RecvSide Parameter> <value>

◊ <RecvSide Parameter> <value>

Specifies one of the following: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>


o NPacketsToDrop <integer>




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



If DelayVariationMethod is specified as 1 or 2, then use this parameter to specify the start of the delay variances. The default is 0.


If DelayVariationMethod is specified as 1 or 2, then use this 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

Enable or disable VLAN tagging. The default is 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 to the following syntax:WrSubnet,<SubnetProfileName>,IpFrag,<IpFrag Parameter> <value>

◊ <IpFrag Parameter> <value>

Specifies one of the following: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 should adhere to the following syntax:WrSubnet,<SubnetProfileName>,MacMasquerade, <MAC Parameter><value>

◊ <MAC Parameter> <value>

Specifies one of the following:o Enabled on | off

Enable or disable MAC masquerading. The default is 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 adhere to the following syntax: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.o MacAddressRange <XX:XX:XX:XX:XX:XX-

XX:XX:XX:XX:XX:XX>

Specify the MAC address range (MAC1-MAC2).• Router

Router profile attributes within the test configuration array should adhere to the following syntax:WrSubnet,<SubnetProfileName>,Router,<Router Parameter><value>


Specifies the parameter as one of the following values: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 adhere to the following syntax:WrSubnet,<SubnetProfileName>,MacAddressRanges,<Ranges Parameter> <value>,

◊ <Ranges Parameter> <value>

Specifies the parameter as one of the following values:o MacAddressRange <XX:XX:XX:XX:XX:XX-

XX:XX:XX:XX:XX:XX>

Specify the MAC address range (MAC1-MAC2).

• 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>


Enable or disable IP security for this subnet. The default is off.



o IkePhase1Mode Aggressive | MainSpecify 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.∇ AES-192: AES with a 192-bit key.∇ AES-256: AES with a 256-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,


∇ 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)∇ MODP-1024 (group 2)∇ MODP-1536 (group 5)



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 (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>

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)∇ MODP-768 (group 1)∇ MODP-1024 (group 2)∇ MODP-1536 (group 5)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 (MODP). These options are key exchanges only and do not encrypt the 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.



∇ ESP-AES-256: AES with a 256-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,


∇ SHA-1: The Secure Hash Algorithm version one, part of the U.S. Digital Signature Standard (DSS). This algorithm is considered very 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 adhere to the following syntax:WrSubnet,<SubnetProfileName>,Tunneling,<Tunneling Parame-ter> <value>

◊ <Tunneling Parameter> <value>

Specifies the parameter as one of the following values: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.

• XAuthIKE 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 to the following syntax: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>

Specifies the parameter as one of the following values: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::0Interface ID = 200:FF:FE00:101-200:FF:FE00:1FFPrefix Length = 64 bitsThe 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.



• ForcedPathMTUSubnet 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>


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.

• IPV6Use the IPV6 subnet profile when configuring an IPv6 subnet. Subnet profile IPv6 attributes within the test configuration array should adhere to the following syntax:WrSubnet,<SubnetProfileName>,IPV6,<IPV6 Parameter><value>

◊ <IPV6 Parameter> <value>

Specifies the parameter as one of the following values: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: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 | offEnable 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>

Parameters The input parameters and their values are described below:• <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.• <Parameter> <value>

Specifies one of the following:• Network <X.X.X.X>

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>



Parameters The input parameters and their values are described below:• <ServerProfileName>

The name of the server you are configuring.• <Parameter> <value>


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>

Specifies the parameter as one of the following values: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 3. The default is 0.

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 3. The default is 0.

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>

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values: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 the following syntax: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>

Specifies the parameter as one of the following values: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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to Mcast. Also remember to set the <Port> parameter to 2001 if configuring using default values.

◊ <Mcast Parameter> <value>

Specifies the parameter as one of the following values: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 to the following syntax:WrServerProfile,<ServerProfileName>,Streaming,<Streaming Parameter> <value>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to Streaming. Also remember to set the <Port> parameter to 554 if configuring using default values.

◊ <Streaming Parameter> <value>

Specifies the parameter as one of the following values: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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to Telnet. Also remember to set the <Port> parameter to 23 if configuring using default values.



◊ <Telnet Parameter> <value>

Specifies the parameter as one of the following values: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 characterCR – Carriage ReturnCR/LF – Carriage Return and Line FeedThe 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

array should adhere to the following syntax:WrServerProfile,<ServerProfileName>, Telnet, Command,<Command Entry Number>,<Command Parameter><value>

o Command Entry Number Iterates with each new Command definition within the current ServerProfileName from 0 onwards.

o <Command Parameter><value>

Specifies the parameter as one of the following values:∇ 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>

Specifies the parameter as one of the following values: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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to MMS. Also remember to set the <Port> parameter to 1755 if configuring using default values.

◊ <MMSParameter> <value>

Specifies the parameter as one of the following values: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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to POP3. Also remember to set the <Port> parameter to 110 if configuring using default values.

◊ <Mailbox Number> Iterates with each new Mailbox definition from 0 onwards.

◊ <Mailbox Parameter> <value>

Specifies the parameter as one of the following values: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 used. The default is 256.

o MaximumMessageLength <integer>

The maximum 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 used. The default is 512.

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 should adhere to the following syntax:WrServerProfile,<ServerProfileName>,IMAP4,NumberOfMail-boxes <NumMboxes>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to IMAP4. Also remember to set the <Port> parameter to 143 if configuring using default values.



◊ <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>

Specifies the parameter as one of the following values: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>

Specifies the parameter as one of the following values: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 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 used. The default is 256.

o MaximumMessageLength <integer>

The maximum 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 used. The default is 512.

• 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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to CapRepTCP. Also remember to set the <Port> parameter to 2000 if configuring using default values.

◊ <ActionNumber> Iterates with each new individual action from 0 onwards.

◊ <CapRep Parameter> <value>

Specifies the parameter as one of the following values:o Type <action_type>


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 acceptable action types.



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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to CapRepTCP. Also remember to set the <Port> parameter to 2000 if configuring using default values.


Specifies the parameter as one of the following values: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

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.

• 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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to CapRepUDP. Also remember to set the <Port> parameter to 2000 if configuring using default values.

◊ <ActionNumber> Iterates with each new individual action from 0 onwards.




o Value <value>




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 acceptable action types.

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 within the test configuration array should adhere to the following syntax:WrServerProfile,<ServerProfileName>,CapRepUDP, <CapRep Parameter> <value>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to CapRepUDP. Also remember to set the <Port> parameter to 2000 if configuring using default values.





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. 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.


• 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.

• Capture/Replay Eth Server Profile ParametersIf a PCap file WILL NOT BE uploaded, Capture/Replay Eth server profile entries within the test configuration array should adhere to the following syntax:

WrServerProfile,<ServerProfileName>,CapRepEth, <CapRep Parameter> <value>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to CapRepEth. Also remember to set the <Port> parameter to 2000 if configuring using default values.◊ <CapRep Parameter> <value>



o Value <value>


o Min <integer>




o Max <integer>


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 within the test configuration array should adhere to the following syntax:WrServerProfile,<ServerProfileName>,CapRepEth, <CapRep Parameter> <value>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to CapRepEth. Also remember to set the <Port> parameter to 2000 if configuring using default values.◊ <CapRep Parameter> <value>




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.

o AutoDiscover true | false

Enter “true” to have the client search the Pcap 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. The default value is 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 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 the following syntax:WrServerProfile,<ServerProfileName>,SIPUdp, <SIP Parameter> <value>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to SIP UDP. Also remember to set the <Port> parameter to 5060 if configuring using default values.

◊ <SIP Parameter> <value>

Specifies the parameter as one of the following values: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>

The timeout after which the server picks up the call is randomly chosen between the minimum off-hook time (above) and this maximum off-hook time. The default maximum off-hook time is 20000 milliseconds.Before the timeout expires, the ringing signal is sent to the caller.

• 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 the following syntax:WrServerProfile,<ServerProfileName>,SIPTcp, <SIP Parameter> <value>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to SIP TCP. Also remember to set the <Port> parameter to 5060 if configuring using default values.

◊ <SIP Parameter> <value>

Specifies the parameter as one of the following values: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>

The timeout after which the server picks up the call is randomly chosen between the minimum off-hook time (above) and this maximum off-hook time. The default maximum off-hook time is 20000 milliseconds.Before the timeout expires, the ringing signal is sent to the caller.

• 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>

Note: To instigate this profile within a test, the <ApplicationProtocol> parameter must be set to MM4. Also remember to set the <Port> parameter to 25 if configuring using default values.



◊ <MM4 Parameter> <value>

Specifies the parameter as one of the following values: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 [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 ParametersUse 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 configuration array should adhere to the following syntax: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 ParametersUse 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 configuration array should adhere to the following syntax:WrServerProfile,<ServerProfileName>,MM4,MessageStatusPer-centage, <Parameter> <value>



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 status used in MM4_delivery_report.REQ. The default is 100.

o Deferred <integer>

Specify the random selection percentage for “Deferred” as the message status used in MM4_delivery_report.REQ. The default is 0.

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 status used in MM4_delivery_report.REQ. The default is 0.



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 ParametersUse 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-centage, <Parameter> <value>



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.

◊ NeverHTTP 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.

◊ AfterTimeoutHTTP 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>

Parameters The input parameters and their values are described below:• <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- Beginning2- Middle3- 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 field1 - 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 | offEnable 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 | 3Specify 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), andLastModifiedHeaderProgramPercent (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."The format of this entry must be as follows:<day>, <date> <time> <zone>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""The format of this entry must be as follows:<day>, <date> <time> <zone>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"The format of this entry must be as follows:<day>, <date> <time> <zone>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>

Parameters The input parameters and their values are described below:• <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>

The input parameters and their values are described below:• <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}


Chapter 3: Test Configuration ArrayClustered Test Configuration Array Parameters

Clustered Test Configuration Array ParametersAll 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 the following syntax: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.


Chapter 3: Test Configuration ArrayGlobal Test Configuration Array Parameters

Global Test Configuration Array ParametersThis 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>


Specifies one of the following:• 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.


Chapter 3: Test Configuration ArrayGlobal Test Configuration Array Parameters

• 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: FunctionsClustered Functions

Clustered FunctionsThe 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



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



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



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>




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).



• {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



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



• <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.



• <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”Can be “full”, “summary”, or “quick”

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.


Chapter 4: FunctionsQuery Functions

Query FunctionsYou 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.



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.



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


Chapter 4: FunctionsSpirent 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 FunctionsSpirent 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)

#

lappend stcProvisionList [list "192.168.0.2:1,1" \

"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]"


Chapter 4: FunctionsAppliance Functions

# Release all cards

SPI_AV::STC::CleanUp

# Test complete

puts "Test Complete"

Appliance FunctionsAppliances 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> ...



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

IP address of the appliance• unitNo

Appliance unit/port group number, or 10GbE virtual port number (zero-relative)• user

User ID in the form of <username>@<hostname>• reserveState

0 – Not previously reserved by the same user1 – 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

IP address of the appliance



• unitNo

Appliance unit/port group number, or 10GbE virtual port number (zero-relative)• user

User ID in the form of <username>@<hostname>• reserveState

0 – Not previously reserved by the same user1 – 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).


Chapter 4: FunctionsStandard Functions

Standard FunctionsThe 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



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>



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 0The 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}\WaUserProfile,ConnsPerSec_up2_1,LoadProfile {ConnsPerSec_lp2}\WaUserProfile,ConnsPerSec_up3_2,LoadProfile {ConnsPerSec_lp3}\WaUserProfile,ConnsPerSec_up4_3,LoadProfile {ConnsPerSec_lp4}\

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



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• <localDirectory>

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.



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>]


IP address of the device or Spirent TestCenter port group ID• <userId>



• <unitNumber>

Optional, defaults to 0The 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


Module)

Return Value Returns a list of index/value pairs representing the current admin configuration.

Comments None

Example Return (index: value)

adminNetworkConfig,defaultDomainName:

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



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>

Optional, defaults to 0The 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)

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:

value):

... ... ... ... ... ... ...

eventLog,6,: 10.7.18.100 <7303195>: WebAvalanche Version: 6.2.0.30909 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>]







• <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>]





• <unitNumber>



Module)

Return Value Returns a list of index/value pairs representing the interface list.

Comments None



Example Return (index: value):





GetLastError

Description Returns the last error encountered by the dispatcher process running on the specified appliance.

Syntax SPI_AV::GetLastError <ipAddress>


IP address of the device or Spirent TestCenter port group ID

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>]





• <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 Return (index:

value):

stats,stats,tcp,attemptedConnRate: 1

stats,stats,tcp,attemptedConns: 10

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>]







• <unitNumber>



Module)

Return Value Returns a list of index/value pairs representing the current status.

Comments None

Example Return (index: value):

unitStatusList,0,exitCode: 0

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>

Optional, defaults to ""



• <username>@<hostname>


• <unitNumber>



Module)

Return Value None

Comments None


Chapter 4: FunctionsInteractive Testing Functions

Interactive Testing FunctionsUse 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>]






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>]





• <unitNumber>

Optional, defaults to 0



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


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>

Optional, defaults to "4"Number of interfaces to cater for on the client side

• <numServerInterfaces>

Optional, defaults to "4"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

• <localDirectory>

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>




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>

Unique ID (name) of the test to run• <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>

Unique ID (name) of the test to run• <statsMode>

Optional, defaults to "full"Can be “full”, “summary”, or “quick”

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>]






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>



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>

Unique ID (name) of the test to run

• <statsMode>

Optional, defaults to "full"Can be “full”, “summary”, or “quick”

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>




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 IndicesClient Statistics Message Indices

Client Statistics Message IndicesThe 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,abortedSessionsPerSec

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

Appendix A: Statistics Message IndicesFilters to Use for Client Statistics

Filters to Use for Client StatisticsThis 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 = Bandwidth1 = Connections2 = Connections/second3 = SimUsers4 = SimUsers/second5 = Transactions6 = Transactions/second7 = BodyBytes10 = SimUsers/hour11 = Connections/hour12 = 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 show the network and/or device under test behavior when responding to a number of 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

The total number of TCP connections that transitioned from the Closed state to the 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

The total number of TCP connections that transitioned from the CloseWait state to the 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

The total number of TCP connections that transitioned from the Closing state to the 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

The total number of TCP connections that transitioned from the Established state to the CloseWait state.

• tcpstate,estb_to_FinWait1

The total number of TCP connections that transitioned from the Established state to the 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

The total number of TCP connections that transitioned from the FinWait1 state to the Closing state.

• tcpstate,finWait1_to_FinWait2

The total number of TCP connections that transitioned from the FinWait1 state to the FinWait2 state.

• tcpstate,finWait1_to_TimeWait

The total number of TCP connections that transitioned from the FinWait1 state to the 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 total number of TCP connections that transitioned from the SynReceived state to 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

The total number of TCP connections that transitioned from the SynSent state to the Established state.

• tcpstate,synSent_to_SynRcvd

The total number of TCP connections that transitioned from the SynSent state to the 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 (main page or file) from the server.

• 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 (main page or file) from the server.

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 phase 1 (Remote Access tunnel only).

• ipsec,XAuthSuccesses

The number of successful authentications, using XAuth (Extended Authentication) for phase 1 (Remote Access tunnel only).



• 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).


Appendix A: Statistics Message IndicesServer Statistics Message Indices

Server Statistics Message IndicesThe 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:pop3,abortedSessionsPerSec


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.


Appendix A: Statistics Message IndicesFilters to Use for Server Statistics

Filters to Use for Server StatisticsThis 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 sessions. These statistics show the network and/or device under test behavior when 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 sessions. These statistics show the network and/or device under test behavior when 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

The length of the received queue, which is the number of packets that are yet to be 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

The length of the received queue, which is the number of packets that are yet to be 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 show the network and/or device under test behavior when responding to a number of 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

The total number of TCP connections that transitioned from the Closed state to the Listen state.

• tcpstate,closed_to_SynSent

The total number of TCP connections that transitioned from the Closed state to the 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

The total number of TCP connections that transitioned from the CloseWait state to the 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

The total number of TCP connections that transitioned from the Closing state to the 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

The total number of TCP connections that transitioned from the Established state to the CloseWait state.

• tcpstate,estb_to_FinWait1

The total number of TCP connections that transitioned from the Established state to the FinWait1 state.





• tcpstate,finWait1_to_Closing

The total number of TCP connections that transitioned from the FinWait1 state to the Closing state.

• tcpstate,finWait1_to_FinWait2

The total number of TCP connections that transitioned from the FinWait1 state to the FinWait2 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 SynReceived 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 total number of TCP connections that transitioned from the SynReceived state to 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

The total number of TCP connections that transitioned from the SynSent state to the Established state.



• tcpstate,synSent_to_SynRcvd

The total number of TCP connections that transitioned from the SynSent state to the 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.

MM4The 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,forwardResponsesSentPerSecThe 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 FilesSample Configuration File

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" "Copper" "Full" "1000" "Enable"]

lappend stcProvisionList [list "10.47.20.20:2,9" "c0-e5-0e-00-00-34" "Copper" "Full" "1000" "Enable"]

lappend stcProvisionList [list "10.47.20.20:2,10" "c0-e5-0e-00-00-35" "Copper" "Full" "1000" "Enable"]



#

# 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}\


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-tion {AdvDevOpenConns_inf1}\



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-file,OpenConns_lp,Steps,Step,1,Label {Ramp Up}\

WaLoadProfile,OpenConns_lp,Steps,Step,1,Ramp-Time {10}\



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}\



WaLoadPro-file,OpenConns_lp,Steps,Step,3,Label {Steady State}\

WaLoadProfile,OpenConns_lp,Steps,Step,3,Pat-tern {Stair}\





WaLoadPro-file,OpenConns_lp,Steps,Step,4,Label {Ramp Down}\


\

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-ble,StaticRoutingTable_0_1 {1}\

\

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}\


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}\



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-ble {StaticRoutingTable_0_1}\

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 {AdvDevOpenConns_inf1}\

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-tion {AdvDevOpenConns_inf0}\

WrInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquer-ade,Mac0 {12}\


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-tion {AdvDevOpenConns_inf1}\





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-ble,StaticRoutingTable_0_0 {1}\

WrStaticRouteTa-ble,StaticRoutingTable_0_1 {1}\

\

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}\


WrSubnet,echo_sn0,Network {192.168.42.0}\

WrSubnet,echo_sn0,RecvSide,NPacketsTo-Drop {1}\

WrSubnet,echo_sn0,Router,StaticRouteTa-ble {StaticRoutingTable_0_0}\

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}\



WrSubnet,echo_sn1,Network {192.168.43.0}\

WrSubnet,echo_sn1,RecvSide,NPacketsTo-Drop {1}\

WrSubnet,echo_sn1,Router,StaticRouteTa-ble {StaticRoutingTable_0_1}\

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 {AdvDevOpenConns_inf0}\

WrTestProfile,Unit0,Inter-face,0,PhysIf {0}\

WrTestProfile,Unit0,Interface,1,Name {AdvDevOpenConns_inf1}\

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-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

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-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

WrTransactionProfile,caw512k,ExpiresHeaderPro-gram {2}\

WrTransactionProfile,caw512k,ExtendedHttpHead-ers {}\

WrTransactionProfile,caw512k,LastModified-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

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-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

WrTransactionProfile,Data,ExpiresHeaderPro-gram {2}\

WrTransactionProfile,Data,ExtendedHttpHead-ers {}\



WrTransactionProfile,Data,LastModified-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

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-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

WrTransactionProfile,Default,ExpiresHeaderPro-gram {2}\

WrTransactionProfile,Default,ExtendedHttpHead-ers {}\

WrTransactionProfile,Default,LastModified-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

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-Header {Thu, 01 Jan 1970 00:00:17 GMT}\



WrTransactionProfile,Delay,ExtendedHttpHead-ers {}\

WrTransactionProfile,Delay,LastModified-Header {Thu, 01 Jan 1970 00:00:17 GMT}\

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}\

]


Appendix B: Sample FilesSample Test Script

Sample Test ScriptThe 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} {




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

#



set auto_path [linsert $auto_path 0 "C:/Program Files/Spirent Com-munications/Spirent TestCenter 2.10/Layer 4-7 Application/TclAPI"]

package forget SPI_AV

package require SPI_AV

#

# Initialize the API

#

SPI_AV::InitializeAPI

#

# 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"



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



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 $testDirectory $testId

puts " - done"

puts -nonewline "Uploading Test To Server Cluster"; flush stdout

SPI_AV::ClusterController::UploadClusteredTest $serverClusterID $testDirectory $testId

puts " - done"



#

# 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"



#

# 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}

}



# 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 ScriptsTroubleshooting Common Problems

Troubleshooting Common ProblemsThis 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.gz2 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::InitializeAPI 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" "Copper" "Full" "100" "Enable"]

lappend stcProvisionList [list "10.47.52.21:3,2" "a4-b4-89-00-00-1d" "Copper" "Full" "100" "Enable"]

lappend stcProvisionList [list "10.47.52.21:4,1" "a4-b4-89-00-00-21" "Copper" "Full" "100" "Enable"]

lappend stcProvisionList [list "10.47.52.21:4,2" "a4-b4-89-00-00-26" "Copper" "Full" "100" "Enable"]

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.

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

ESD protective surface or matOptional resistor

Wrist strap

ESD protective floor mat (optional)


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

AAbortClusteredTest function 183AddLicense function 201AddUnitToCluster function 183AdjustLoad function 201Avalanche appliance software

upgrading 18

Ccleaning guidelines, fiber optics 295CleanUp function 194, 197, 203ClearEventLog function 213ClearEventLogs function (cluster) 184Clustered Parameters 177configuration array

modifying 24, 25, 26CreateCluster function 184

DDebugLogFile function 214DeleteCluster function 184DownloadCookies function 203Dump function 203

Eequipment handling

ESD service kits 294preparing your workstation 294

ESD requirements 293

Ffunctions 191, 194, 197, 200, 212

ClusteredAbortClusteredTest 183AddUnitToCluste 183ClearEventLogs (cluster) 184CreateCluster 184DeleteCluster 184GenerateClusteredTest 185GetClusteredTestResults 185IsClusteredTestRunning 186RegisterStatsCallback (cluster) 186RemoveClusteredTest 187RemoveUnitFromCluster 187StartClusteredTest 188StopClusteredTest 188

UnregisterStatsCallback 188UploadClusteredTest 189ValidateClusteredTest 189WaitForClusteredTestCompletion 190

Interactive TestingClearEventLog 213DebugLogFile 214GenerateTest 214GetTestResults 215GetTestStage 216IsTestRunning 216RegisterStatsCallback 216RemoveTest 218StartSNMPPolling 218StartTest 219StopSNMPPolling 219StopTest 220UnregisterStatsCallback 220UploadTest 221ValidateTest 221Version 222WaitForTestCompletion 222

QueryGetParameter 191GetProfileName 191GetProfileParameters 192GetProfileType 192GetValidProfileType 193SetParameter 193

Spirent TestCenterCleanUp 194, 197ProvisionPorts 195, 198

StandardAddLicense 201AdjustLoad 201CleanUp 203DownloadCookies 203Dump 203GetAdminConfig 204GetEventLog 205GetHostList 206GetInterfaceList 207GetLastError 208GetNumInterfaces 208GetRealTimeStats 208GetStatus 209


Index

InitializeAPI 210Reboot 210

GGenerateClusteredTest function 185GenerateTest function 214GetAdminConfig function 204GetClusteredTestResults function 185GetEventLog function 205GetHostList function 206GetInterfaceList function 207GetLastError function 208GetNumInterfaces function 208GetParameter function 191GetProfileName function 191GetProfileParameters function 192GetProfileType function 192GetRealTimeStats function 208GetStatus function 209GetTestResults function 215GetTestStage function 216GetValidProfileType function 193Global test profile 178

Hhardware requirements

Spirent TestCenter chassis 9

IInitializeAPI function 210installation

hardware 9Interactive Testing functions 212IsClusteredTestRunning function 186IsTestRunning function 216

JJava

installing 14

Mmessages

printing results 37

Nnotation conventions

reference manual 8

Pprofile

server 139user 75

ProvisionPorts function 195, 198

QQuery functions 191

RReboot function 210RegisterStatsCallback function 216RegisterStatsCallback function (cluster) 186RemoveClusteredTest function 187RemoveTest function 218RemoveUnitFromCluster function 187requirements

electrostatic discharge 293

Ssample test script

modifying 28Scripting API

configuring a test 20installing 15running a test 20supported functionality 17

scriptsdebugging 38modifying 28

Server Content Upload Parameters 176server profile 139SetParameter function 193Spirent TestCenter

chassis support 9hardware requirements 9modifying a configuration array for 26test configuration array 26

Spirent TestCenter functions 194, 197Standard functions 200StartClusteredTest function 188StartSNMPPolling function 218StartTest function 219statistics

displaying 37StopClusteredTest function 188StopSNMPPolling function 219StopTest function 220

Ttest configuration array

Avalanche/Client parameters 41, 178Clustered parameters 177clustered parameters 177Global 178modifying 24, 25, 26profile entry format 40rReflector/Server parameters 119samples 21test profile parameters 177Transaction Profile 167WaCapRepEth 111WaCapRepTCP 106WaCapRepUDP 109WaCertificate 117, 176WaContent 114WaDDOSConfig 95


Index

WaFormDatabase 114WaHostFile 117WaHttpContent 115, 116WaInterface 56WaLoadProfile 45WaNetworkProfile 52WaPPPGroupProfile 92WaPPPoEGroupParams 95WaStaticRouteTable 89WaSubnet 60WaTelnetProfile 90WaTestProfile 42WaUrlList 88WaUserProfile 75WrContent 176WrInterface 123WrNetworkProfile 121WrServerProfile 139WrStaticRouteTable 139WrSubnet 125WrTestProfile 120

test resultscollecting 37printing 37

test scriptsdebugging 38samples 21

testssamples included with API 24

Transaction Profile 167

UUnregisterStatsCallback function 220UnregisterStatsCallback function (cluster) 188Upgrading appliance software 18UploadClusteredTest function 189UploadTest function 221user profile 75

VValidateClusteredTest function 189ValidateTest function 221Version function 222

WWaCapRepEth 111WaCapRepTCP 106WaCapRepUDP 109WaCertificate 117, 176WaContent 114WaDDOSConfig 95WaFormDatabase 114WaHostFile 117WaHttpContent 115, 116WaInterface 56WaitForClusteredTestCompletion function 190WaitForTestCompletion function 222WaLoadProfile 45

WaNetworkProfile 52WaPPPGroupProfile 92WaPPPoEGroupParams 95WaStaticRouteTable 89WaSubnet 60WaTelnetProfile 90WaTestProfile 42WaUrlList 88WaUserProfile 75workstation preparation 294WrContent 176WrInterface 123WrNetworkProfile 121WrServerProfile 139WrStaticRouteTable 139WrSubnet 125WrTestProfile 120


Documents

L4 7 Scripting API