L4 7 Scripting API

Reference Manual

Scripting API for the Layer 4-7 Application January 2008

P/N 71-003808 REV A

Spirent Communications, Inc. 26750 Agoura Road Calabasas, CA 91302 USA

Copyright © 2008 Spirent Communications, Inc. All Rights Reserved. All of the company names and/or brand names and/or product names referred to in this document, in particular, the name “Spirent” and its logo device, are either registered trademarks or trademarks of Spirent plc and its subsidiaries, pending registration in accordance with relevant national laws. All other registered trademarks or trademarks are the property of their respective owners. The information contained in this document is subject to change without notice and does not represent a commitment on the part of Spirent Communications. The information in this document is believed to be accurate and reliable, however, Spirent Communications assumes no responsibility or liability for any errors or inaccuracies that may appear in the document.

Limited Warranty Spirent Communications, Inc. (“Spirent”) warrants that its Products will conform to the description on the face of order, that it will convey good title thereto, and that the Product will be delivered free from any lawful security interest or other lien or encumbrance. Spirent further warrants to Customer that hardware which it supplies and the tangible media on which it supplies software will be free from significant defects in materials and workmanship for a period of twelve (12) months, except as otherwise noted, from the date of delivery (the “Hardware Warranty Period”), under normal use and conditions. To the extent the Product is or contains software (“Software”), Spirent also warrants that, if properly used by Customer in accordance with the Software License Agreement, the Software which it supplies will operate in material conformity with the specifications supplied by Spirent for such Software for a period of ninety (90) days from the date of delivery (the “Software Warranty Period”). The “Product Warranty Period” shall mean the Hardware Warranty Period or the Software Warranty Period, as applicable. Spirent does not warrant that the functions contained in the Software will meet a specific requirement or that the operation will be uninterrupted or error free. Spirent shall have no warranty obligations whatsoever with respect to any Software which has been modified in any manner by Customer or any third party. Defective Products and Software under warranty shall be, at Spirent's discretion, repaired or replaced or a credit issued to Customer's account for an amount equal to the price paid for such Product provided that: (a) such Product is returned to Spirent after first obtaining a return authorization number and shipping instructions, freight prepaid, to Spirent's location in the United States; (b) Customer provides a written explanation of the defect or Software failure claimed by Customer; and (c) the claimed defect actually exists and was not caused by neglect, accident, misuse, improper installation, improper repair, fire, flood, lightning, power surges, earthquake, or alteration. Spirent will ship repaired Products to Customer, freight prepaid, based on reasonable best efforts after the receipt of defective Products. Except as otherwise stated, any claim on account of defective materials or for any other cause whatsoever will conclusively be deemed waived by Customer unless written notice thereof is given to Spirent within the Warranty Period. Spirent reserves the right to change the warranty and service policy set forth above at any time, after reasonable notice and without liability to Customer. TO THE EXTENT PERMITTED BY APPLICABLE LAW, ALL IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, ARE HEREBY EXCLUDED, AND THE LIABILITY OF SPIRENT, IF ANY, FOR DAMAGE RELATING TO ANY ALLEGEDLY DEFECTIVE PRODUCT SHALL BE LIMITED TO THE ACTUAL PRICE PAID BY THE CUSTOMER FOR SUCH PRODUCT. THE PROVISIONS SET FORTH ABOVE STATE SPIRENT'S ENTIRE RESPONSIBILITY AND CUSTOMER'S SOLE AND EXCLUSIVE REMEDY WITH RESPECT TO ANY BREACH OF ANY WARRANTY.

Contents About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Hardware Handling/Cleaning Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 How to Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Scripting API Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Installing Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Installing the Scripting API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 On Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 On Linux or Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Upgrading Appliance Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Sample Test Configuration Arrays and Test Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Generate Tcl Scripts from the Layer 4-7 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Setting a Custom Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Checksum in Sample Configuration Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

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

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

Contents

Chapter 4: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Clustered Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 General Terminology for Clustered Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Query Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Spirent TestCenter Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Appliance Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Standard Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Interactive Testing Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

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

4

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

Contents

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

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

Appendix C: Troubleshooting Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Troubleshooting Common Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Check your environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Check your debug logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Check the autopath, license directory, and LD_LIBRARY_PATH . . . . . . . . . . . . . . . . 291 Check Spirent TestCenter provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

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

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

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297


6


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

Scripting API for the Layer 4-7 Application Reference Manual

| 7

About this Guide Introduction

Introduction This reference manual provides detailed information on the Tcl scripting API you can use to generate simulated, realistic Internet conditions and load. The Tcl API commands make it easy to configure and run scripting tests from your command interface. This manual is for users running Layer 4-7 tests on Spirent TestCenter ports within a Spirent TestCenter chassis, as well as Avalanche appliances. These users include:

•

Network equipment manufacturers (NEMs) and service providers who need to test multi-function devices such as firewalls, VPN, routing, and web switching.

•

IT professionals testing large enterprise networks and Web infrastructures.

It is assumed that users of this guide are familiar with Microsoft Windows® and Spirent TestCenter, or appliance equipment, and have an intermediate knowledge of data communications theory. Familiarity with Avalanche™ 6.5 or higher software and/or ActiveState ActiveTcl™ software is preferred, but not required. Please see the Release Notes for the ActiveTcl version to use for this release.

Notation Conventions The following notational conventions are used throughout this manual:

8

Notation

Example

Meaning and Use

Courier typeface

WaTestProfile

Indicates elements such as names of parameters, functions, files, and directories.

Angle brackets

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

{ }

Indicates a Tcl list.

Vertical bar

None | PAP | CHAP

Separates items in a list. You must choose only one item.

Ellipsis dots

...

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 Guide Related Documentation

Related Documentation See the following documents for information about products that work with the Layer 4-7 Tcl scripting API:

•

Spirent TestCenter Layer 4-7 Application Quick Start Guide - Provides a summary of the major steps you use to set up and run an HTTP-based Quick test on a Spirent TestCenter chassis using the Layer 4-7 Application.

•

Avalanche Commander Quick Start Guide - Provides a summary of the major steps you use to set up and run an HTTP-based Quick test on one Avalanche client appliance and one Avalanche server appliance using Avalanche Commander.

•

Avalanche Analyzer online Help - Describes the Avalanche Analyzer user interface, which allows you to view test result files generated by the Layer 4-7 Application.

•

Avalanche URL Trace Tool online Help - Describes the Avalanche URL Trace Tool user interface, which allows you to view URL Trace file results generated by the Layer 4-7 Application.

•

Avalanche Installation Guide - Provides installation instructions for the Avalanche appliance hardware and software.

•

Getting Started with Spirent TestCenter - Provides details on how to install Spirent TestCenter chassis and modules and how to obtain license keys. Information is also provided on module LEDs, multiple chassis connections, cables, and chassis commands.

•

Layer 4-7 Application online help – Provides information on all procedures required to prepare your testing environment for running tests on a Spirent TestCenter chassis, and Avalanche appliances.

•

Spirent TestCenter System Reference Manual - Provides application overview information, and directs you to appropriate sources for the latest detailed product descriptions.

Note: The Layer 4-7 documentation is located in your installation’s documentation directory. This document is located in your TclAPI installation “Documentation” directory. The Spirent TestCenter documentation is available with your product’s installation.


About this Guide Hardware Handling/Cleaning Practices

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

10 |


About this Guide How to Contact Us

How to Contact Us To obtain technical support for any Spirent Communications product, please contact our Support Services department using any of the following methods:

Americas E-mail: [email protected] Web: http://support.spirentcom.com Toll Free: +1 800-SPIRENT (+1 800-774-7368) (US and Canada) Phone: +1 818-676-2616 Fax: +1 818-880-9154 Hours: Monday through Friday, 05:30 to 16:30, Pacific Time

Europe, Africa, Middle East 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


12 |


Chapter 1

Introduction This chapter introduces the Scripting API for the Layer 4-7 Application Reference Manual, provides a list of the system and PC requirements necessary to run this software, and describes how you get started.

In this chapter... •

Scripting API Overview . . . . 14

•

Installing Java . . . . 14

•

Installing the Scripting API . . . . 15

•

Supported Configurations . . . . 17

•

Upgrading Appliance Software . . . . 18

•

Getting Started . . . . 20

•

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


Chapter 1: Introduction Scripting API Overview

Scripting API Overview The Scripting API for the Layer 4-7 Application is a Tcl-based API that provides the same functionality you have with the Layer 4-7 Application: you can create and run tests on appliances and Spirent TestCenter ports within a Spirent TestCenter chassis. Use the Tcl commands described in this manual to create a user-specific test script. Consult a standard Tcl reference document for general Tcl information. For the correct version of the ActiveState Active Tcl to use, please see the Release Notes. If you do not have the required version, you can download the version for your platform from one of the following ftp sites: ftp://ftp.activestate.com/ActiveTcl/Linux/ ftp://ftp.activestate.com/ActiveTcl/Solaris/ ftp://ftp.activestate.com/ActiveTcl/Windows/ When you run a test, your script controls the starting and stopping of clients and servers. You do not need to be present to run tests or collect results. Please see the Release Notes for information about system requirements, cable requirements, PC requirements, and network connectivity.

Installing Java Note: The Layer 4-7 Application includes Java when installed in a Windows environment. Therefore, you do not need to install Java, if you plan to run a Layer 4-7 test in a Windows environment. You need to install Java only if you plan to run a Layer 4-7 test in a Unix (Linux/Solaris) environment. To install Java:

14 |

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/javase/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 “” sh: JAVA_HOME =“” export JAVA_HOME bash: export JAVA_HOME=“”


Chapter 1: Introduction Installing the Scripting API

Notes: •

On Linux and Solaris platforms, you must add the Java executable path into either the PATH or JAVA_HOME environment variable for the result files to be merged seamlessly. If one of these environment variables is not set correctly, the following error will appear at the end of a test run during the result files merge time:

Transferring Client Cluster ResultsERROR: Error invoking merge: couldn't execute "java": no such file or directory

•

On Windows machines, you do not need to set the JAVA_HOME or PATH environment variable.

Installing the Scripting API You use the Scripting API for the Layer 4-7 Application to establish a connection and configure your appliances or Spirent TestCenter cards. For Linux and Solaris systems, the Scripting API software can be downloaded from the Spirent Communications Customer Service Center website at http://support.spirentcom.com or copied from the CD shipped with your order. The Scripting API software for Windows XP SP2 is automatically installed when you install the Layer 4-7 Application. See the Release Notes for step-by-step instructions on installing the Scripting API for the Layer 4-7 Application.

On Windows To Install the Scripting API Software on Windows XP Run the Layer 4-7 Application installation program on your Windows XP PC, and follow the instructions in the InstallShield Wizard. Note: When you uninstall the software (via Add/Remove Programs on your PC), additional files may be left in the installation directory. The uninstaller only removes those files explicitly installed by the installer, and does not remove any additional files or directories created after installation.

On Linux or Solaris To Install the Scripting API Software on Linux or Solaris Be sure to read the Release Notes for important installation, configuration, and test guidelines that may have been updated since this document was written. This section of the documentation covers important information for successfully installing the Scripting API software on Linux or Solaris machines. Also, read the Release Notes for additional information about installing the Tcl API on Linux and Solaris machines.


Chapter 1: Introduction Installing 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 tarball: 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: |_ 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=“//Spirent_ TestCenter_2.xx/Layer_4_7_Application_Solaris/STC:/ /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)

16 |


Chapter 1: Introduction Supported Configurations

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

Supported Configurations This section provides a brief overview of the various capabilities of the scripting API.

Current Supported Functionality The API supports the following features:

• Creation and manipulation of Client Load, Network, Interface, Subnet, and User profiles

• Creation and manipulation of Server Network, Interface, Subnet, Server, and Transaction profiles

• Ability to create, start, and stop a test • Ability to retrieve results from a test.


Chapter 1: Introduction Upgrading Appliance Software

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

To upgrade appliance software 1

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

2

Transfer the avalanche_.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_.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 Commander 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

18 |


Chapter 1: Introduction Upgrading 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_.tgz bye

To upgrade the image currently in use: telnet 10.20.30.40 login: root password: welcome /swat/bin/upgradeswat

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_.tgz bye

To upgrade the image currently in use: telnet 10.20.30.40 login: root password: welcome shutdown -f


Chapter 1: Introduction Getting Started

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

Check license and network information.

2

Select the hardware that you want to use with the test.

3

Configure the client and server in the test configuration file.

4

Create or modify one of the Tcl test scripts.

5

Run, validate, and monitor the test.

6

View and analyze test results.

For detailed information on checking license and network information and setting up the hardware to use with your test, see the Layer 4-7 Application online help). To configure and run a test on devices using the scripting API, you must first set up the required test parameters in a test configuration array file. You use any text editor to modify the parameters in a provided sample test configuration array file. At a minimum, you must modify the provisioning entries for Spirent TestCenter ports. Once you configure the test configuration array, you can modify the test script to run the test. This script contains a call to the file containing the test configuration array you modified. You must check to be sure that the following parameters in your test script are correct and modify them if necessary:

• Path to the core API files (set auto_path command) • Path to the file containing the test configuration array (source 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.”

20 |



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



On a Unix (Linux/Solaris) platform, enter the following in the console window in which the Tcl script will run: export USER= (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.

22 |


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.


Configuring Tests . . . . 24

•

Executing Scripts . . . . 31

•

Validating Scripts . . . . 36

•

Printing and Collecting Test Results . . . . 37

•

Debugging a Test Script . . . . 38


Chapter 2: Using the Scripting API Configuring Tests

Configuring Tests If you are using a Windows machine, we recommend that you use the “Generate Tcl Test” feature in the Layer 4-7 Application to generate your Tcl scripts. The resulting Tcl test files (a test configuration array and a Tcl test script) are stored in the specified output directory. See the Layer 4-7 Application online Help topic “Converting a Test to a Tcl Script” for more information. If you are using a Solaris or Linux machine, we recommend that you start by copying and then modifying one of the sample scripts packaged with your software. The Scripting API for the Layer 4-7 Application includes several sample test configuration arrays and Tcl test scripts. Modifying a sample test involves two types of files:

• A file containing the test configuration array parameters (config.tcl) • A Tcl script that sources the configuration array and runs the test (test.tcl) Note: You can also create one file that contains both the configuration array and the test script. You can run the sample Tcl API scripts on one of the following platforms:

• Appliance • Spirent TestCenter The sample scripts are available in the Tcl API branch under the ../SampleTests directory. Appendix B, “Sample Files” also contains a printout of the sample configuration file for Spirent TestCenter (config.tcl)and its corresponding sample test script (test.tcl). However, refer to the set of sample scripts packaged with the Tcl API for the most recent API scripts. To configure and run a client/server test: 1

Check license and network information.

2

Select the hardware to use with your test.

3

Create or modify the required test parameters in the test configuration file.

4

Create or modify a Tcl test script.

5

Run, validate, and monitor the test.

6

View and analyze test results.

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

24 |



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 configuration array for a 2500 appliance, go to /SampleTests/OpenConns/ApplianceVersion.

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

26 |

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 following format: :,. 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 changing 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 provision list, which you can modify for your configuration. # \ # # 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 provisioning 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 command) • Path to the file containing the test configuration array (source 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 Communications/Spirent TestCenter 2.xx/Layer 4-7 Application/TclAPI"]

4

28 |

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

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 “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 Communications/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 ...

7

Modify the “source” command with the path to the file containing the test configuration array to use for this test, for example: source "./STC/AdvDevOpenConns/config.tcl"

30 |

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.


Chapter 2: Using the Scripting API Executing Scripts

Executing Scripts Before running a test, make sure all the systems you intend to use (clients or servers) are up and running. Spirent Communications recommends that, when creating a new test, you start with a small load to verify the connectivity between clients and servers, and the device or infrastructure under test. Once connectivity has been established, you should start incrementally increasing the amount of traffic generated until the desired load is achieved. The creation of a high load on the first test, without first establishing connectivity, might lead to problems that are easier to identify with a test with a small amount of traffic. Note: We strongly recommend that you run your scripts in separate Tcl shells, instead of running several tests or the same test several times in the same Tcl shell. To run a test script: 1 2

Open a new window. If you are using Windows, choose Run from the Start menu, enter cmd, and then click OK. 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 functions 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 puts "\tTIME (seconds)

: $dataArray(http,abortedTxns)" Elapsed

: $dataArray(timeElapsed)"

puts "\t\t\tRemaining : $dataArray(timeRemaining)" } puts "" }

# # Define a Server callback procedure # proc serverStatsCallbackProc {clusterID data} { array set dataArray $data

catch { puts "Server Per second puts "Server Open

: $dataArray(tcpConn,connsPerSec)" : $dataArray(tcpConn,openConns)"

puts "Server Closed with error : $dataArray(tcpConn,closedWithError)" puts "Server Closed with reset : $dataArray(tcpConn,closedWithReset)"

32 |



puts "Server Closed no error Error)"

: $dataArray(tcpConn,closedWithNo-

puts "\tTIME (seconds)


Elapsed

} 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 serverStatsCallbackProc), 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 “serverStatsCallbackID” 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 STC Port (10.47.20.21:1,2) provisioned SUCCESSFULLY STC Port (10.47.20.21:1,3) provisioned SUCCESSFULLY STC Port (10.47.20.21:1,4) provisioned SUCCESSFULLY STC Port (10.47.20.21:1,5) provisioned SUCCESSFULLY STC Port (10.47.20.21:1,6) provisioned SUCCESSFULLY STC Port (10.47.20.21:1,7) provisioned SUCCESSFULLY



STC Port (10.47.20.21:1,8) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,1) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,2) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,3) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,4) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,5) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,6) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,7) provisioned SUCCESSFULLY STC Port (10.47.20.21:2,8) 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 Server Open

: 0

: 0

Server Closed with error : 0 Server Closed with reset : 0 Server Closed no error TIME (seconds)

: 0 Elapsed

: 12

- done Waiting For Client Cluster To CompleteServer Per second Server Open

: 0


: 0 Elapsed

Client Attempted

: 2706

Client Successful

: 2704

Client Unsuccessful : 0

34 |


: 16

: 0


Client Aborted

: 0

TIME (seconds)

Elapsed

: 4

Remaining : 208

Server Per second

: 16921

Server Open

: 18

Server Closed with error : 0 Server Closed with reset : 72473 Server Closed no error

: 0

TIME (seconds)

Elapsed

Client Attempted

: 116092

Client Successful

: 116077

: 24

Client Unsuccessful : 0 Client Aborted

: 0

TIME (seconds)

Elapsed

: 8

Remaining : 204

Server Per second

: 27733

Server Open

: 31


: 0 Elapsed

: 28


Chapter 2: Using the Scripting API Validating Scripts

Validating Scripts You can trial run test parameters before starting a test by adding the ValidateTest function to your test script. The ValidateTest function trials the test by running once through the Client Actions URL list. It performs an internal consistency check, scanning through configuration files, error checking, and ensuring that all files referenced are available. ValidateTest verifies that all of the URLs are accessible. There is no time limit; it runs

as long as it takes to check each URL once. This process usually finishes quickly, unless the servers are not responding or requests are timing out. If problems are encountered, check the results file to troubleshoot the test. During a trial run, the ValidateTest function generates a PCAP (packet capture) trace file for each individual client and server unit involved in the test, called trace.pcap, showing all the traffic requests and responses as the result of one simulated user. One or more PCAP files shows all the packets sent and received at all interfaces, and can be opened using any sniffer program, such as Ethereal, Netasyst (was Sniffer Pro), or ClearSight. (For more information about accessing PCAP files, see the Analyzing Test Results topic in the online Help.) Also during a trial run, the ValidateTest function generates an XML trace file for individual URLs, which contains errors, bindings of variables, response latency, and so on. One trace file is generated per simulated user, called httptracefile_X_trace.xml, where X is a number that represents the simulated user associated with the file. You can view this file by using the URL Trace Tool. To add the ValidateTest function to one of the sample scripts, you need to replace the function calls to start client and server tests (SPI_AV::ClusterController::StartClusteredTest function calls for $serverClusterID and for $clientClusterID) in the script for the client side. To validate a test: 1

In your test.tcl script, replace “StartClusteredTest” with “ValidateClusteredTest” as follows: SPI_AV::ClusterController::ValidateClusteredTest $clientClusterID $serverClusterID $testId

36 |

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 API Printing and Collecting Test Results

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

Printing Results to a Log File When you run a test, it always creates results files with the extension .csv, which contains the client and server-related test configuration and performance statistics. Results files appear in the same location as your test XML files, except in a folder named “Results.” The exact location of your test results depends on the specified testIDirectory and testId variables in your test script: set testDirectory "C:/TclAPI/2.xx/Build_0045/Appliance/ AdvDevConnsPerSecAppliance" set testId "AdvDevConnsPerSecAppliance"

Test results for the individual client units are stored in a subdirectory named \\results\clientsubtest_. Likewise, test results for the server are stored in a subdirectory named \\results\serversubtest_. 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 \\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 API Debugging a Test Script

Debugging a Test Script If you do not invoke a Tcl command properly, the system returns an error. Each error description usually explains that the command failed and indicates the correct usage of the command. When you are running a test script, it can be difficult to detect which command failed. Including puts statements in the test script can narrow the problem area, because you can see the output at each point in the script where a puts statement occurs. You can also use the built-in stack trace by calling set errorInfo, or type in the commands one at a time. Currently, each API function returns an appropriate error message indicating if it encountered a problem but also returns a 1 if the operation completed successfully. So, you can write code around each API function call that tests to see if it completed successfully. You can also turn debugging on for a TclAPI script for better debugging purposes. You define a single variable, bEnableLogging, as in the following example taken from an automatically generated test script, test.tcl: set bEnableLogging 0; # Enable (1) to create a log file for enhanced debugging

Setting the bEnableLogging variable to 1 causes a test_apilog.log file to be generated in the same location where the script (test.tcl) resides. Important: To ensure communication between the workstation on which you are running the Scripting API for the Layer 4-7 Application and your appliance, or Spirent TestCenter chassis, port number 1415 must not be blocked (for example, with a firewall or access control list).

38 |


Chapter 3

Test Configuration Array This chapter contains the syntax and descriptions of the parameters in a test configuration array file.


Format of a Profile Entry . . . . 40

•

Client Test Configuration Array Parameters . . . . 41

•

Server Test Configuration Array Parameters . . . . 119

•

Clustered Test Configuration Array Parameters . . . . 177

•

Global Test Configuration Array Parameters . . . . 178


Chapter 3: Test Configuration Array Format of a Profile Entry

Format of a Profile Entry The typical format of an entry within the test configuration array is: ,,

•

Specifies the type of profile you are configuring. •

Client (Wa) Enter one of the following types of client profiles: WaTestProfile, WaLoadProfile, WaInterface, WaNetworkProfile, WaSubnet, WaUrlList, 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, WrNetworkProfile, WrInterface, WrSubnet, WrStaticRouteTable, WrServerProfile, WrTransactionProfile, WrDefaultTransactionProfile, WrContent

•

The name to give the profile on the target device. This name is used to reference this profile from within other profiles.

•

One of the valid attributes for the corresponding profile type.

•

The value that the attribute will be assigned within the profile.

40 |


Chapter 3: Test Configuration Array Client Test Configuration Array Parameters

Client Test Configuration Array Parameters This section contains parameters to create and manipulate client Load, Network, Interface, Subnet, and User profiles. The following profiles and parameters are described in this section:

• • • • • • • • • • • • • • • • • • •

WaTestProfile WaLoadProfile WaNetworkProfile WaInterface WaSubnet WaUserProfile WaUrlList WaStaticRouteTable WaTelnetProfile WaPPPGroupProfile WaPPPoEGroupParams WaDDOSConfig WaCapRepTCP WaCapRepUDP WaContent WaFormDatabase WaHttpContent WaCookieJarList WaHostFile



WaTestProfile Usage

Test profile entries for the client within the test configuration array.

Syntax

WaTestProfile,

Parameters

The input parameters and their values are described below:

•

Specifies one of the following: •

Description {}

Provide a description of the test. This description appears in the test results files. •

LoadProfile {}

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

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

Note: See “Clustered Test Configuration Array Parameters” on page 177 for the syntax for Interface attributes within the Test profile for a clustered test. ◊

An integer value within the range 0 - 3, depending upon the total number of available interfaces on the appliance or Spirent TestCenter chassis. ◊

Specifies the parameter as one of the following values: o

Name {}

Specify the name of the Interface Profile to be associated with the interface you specified in . o

42 |

DDOSAttacks { }



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

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

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 performance 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 automatically 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 during a test. The default is off. •

DDOSEnabled on | off

Enables or disables DDOS (Distributed Denial of Service) attacks on a test-wide basis. DDoS is enabled/disabled on a port basis. The default is off.



•

SaveCookieJars on | off

Enables or disables cookie saving. When cookie saving is enabled, the client records all cookies transmitted during a test, enabling you to create Cookie Jar files automatically. Cookie Jar files must not exceed 64 megabytes. The default is off. •

PktTrace on | off Enables or disables the creation of a packet trace file. Enable this option if you want the client to produce a PCAP (packet capture) file in addition to its normal set of results files. The PCAP file (called trace.pcap) shows all packets sent and received, and it can be read by many standard sniffer programs, such as Ethereal, Netasyst (was Sniffer Pro), or ClearSight. The default is off.

•

PktTraceBytes The maximum size of the PCAP file in bytes. The maximum value that you can enter is 9,999,360 bytes, which is also the default.

•

UrlTrace on | off Enables or disables the creation of an XML trace file. Enable if you want an XML trace file for individual URLs, which contains errors, bindings of variables, response latency, and so on. One trace file is generated per simulated user, called httptracefile_X_trace.xml, where X is a number that represents the simulated user associated with the file. You can view this file by using the URL Trace Tool. The default is off.

•

UrlTraceOnError on | off Enable if you want only 4XX and 5XX HTTP error codes and content validation failures reported. The default is on.

•

UserLoadEnabled yes | no Enable for a user-based profile. Use this type of profile if you want multiple load curves, each of which describes the load for an individual user (client) profile. User-based load profiles are associated with a unique user (client) profile. The default is no.

•

Notes

You can enter general notes about your test. Notes attributes within the Test Profile should adhere to the following syntax: WaTestProfile,Notes,

Note: Tcl-sensitive characters are not permitted within any of the Notes parameters. ◊


Technician

Enter the name or ID of the technician associated with this test.

44 |



o

Author

Specify the name or ID of the author associated with this test. o

DuTConfig

Enter information about the device under test (DUT) configuration associated with this test. o

RunName

Enter a descriptive name for the current test run. o

Comments

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


TimeInterval

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 Parameters

WaLoadProfile,,


•

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

•


Description {}

Provide a description of the load profile. •

LoadSpecification



Defines the units in which the load is measured as one of the following values: 0 = Bandwidth 1 = Connections 2 = Connections/second 3 = SimUsers 4 = SimUsers/second 5 = Transactions 6 = Transactions/second 7 = BodyBytes 10 = SimUsers/hour 11 = Connections/hour 12 = Transactions/hour Each value is described below: ◊

Bandwidth

Specifies the amount of data that can be transmitted in a fixed amount of time over all combined interfaces. Bandwidth is usually expressed in bits per second (Kbps). ◊

Connections

Defines the number of simultaneous network connections initiated from the client. This setting generates enough load to reach and sustain a target number of TCP connections. These TCP-based connections include protocols such as HTTP, FTP, and SMTP. Open TCP connections depend on user arrival rates (sessions/second), system efficiency, and user behavior, such as Think Time. Like Sessions, TCP connections are an effect, not a cause, so specifying the same number of TCP connections on different systems does not mean the traffic generated will be the same. An open connection does not necessarily have nonstop activity. This load type is the default value. Use caution when interpreting results using this criteria because a rapidly climbing number of open TCP connections usually means that the system is overloaded or exhibiting latency. Pay attention to the time it takes a TCP connection to complete, the time to SYN/ACK, and the number of successful versus failed transactions at a specified number of open TCP connections. ◊

ConnectionsPerSecond

This load type is often preferred by network equipment manufacturers for testing network devices. One TCP connection can contain up to hundreds of transactions, depending on client profile configuration and server response.

46 |



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 ConnectionsPerSecond rate. When either ConnectionsPerSecond or ConnectionsPerHour 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 performance of the device under test. As the system slows down due to overloading, 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 resulting 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 duration of the test. TransactionsPerSecond might not equal ConnectionsPerSecond 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 47 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 duration of the test. TransactionsPerHour might not equal ConnectionsPerHour 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.

48 |



•

RandomizerSeedMode on | off

Enables or disables RandomizerSeedMode. Enable this mode and enter a number 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

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


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,,Steps,Step,, ∇

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 | Minutes | Hours - Specify the unit of time for the selected step’s

load generation. If you want to experiment with a test of short duration, 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 - 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 - 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 network, start small and increase these parameters proportionately. There is no minimum height requirement, but the upper limit must not exceed 10,000,000. ∇

RampTime - 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 pinpoint the threshold.

50 |

∇

SteadyTime - 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 session 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 - 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 following syntax: WaLoadProfile,,LoadConstraints, ◊


MaxBandwidth

Controls the upper limit for the incoming bandwidth that occurs throughout 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

Controls the upper limit for the total number of Sessions created during a test. o

MaxBirthrate

Controls the upper limit for the number of Sessions created in any second throughout the test. o

MaxLiving

Controls the upper limit for the number of concurrently running Sessions. o

MaxConnectionsAttempts

Controls the upper limit for the number of connection attempts that are made throughout the test. o

MaxNewConnectionsPerSecond

Controls the upper limit for the number of open connections created in any second throughout the test. o

MaxOpenConnections

Controls the upper limit for the number of open connections. The default is 100. o

MaxConnectionsErrorsPercent

Controls the upper limit for the percentage of connection errors that occur during any second throughout the test. o

MaxTransactionAttempts

Controls the upper limit for the number of transaction attempts that are made throughout the test.



o

MaxNewTransactionsPerSecond

Controls the upper limit for the number of transactions that are requested at any second throughout the test. o

MaxTransactionsErrorsPercent

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

Syntax

Parameters

WaNetworkProfile,,


•

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

•


Description {}

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.

52 |



•

FairnessThreshold

Specifies the throughput (fairness) threshold per connection that you expect when testing a DUT/SUT (device/system under test) that performs bandwidth management, traffic shaping, or QoS guarantee. You specify the fairness threshold per connection in bytes/second. All data sent and received inside a particular connection is recorded. The rate for every connection is calculated as follows: (bytes sent + bytes received) / connection lifetime This calculation is based on TCP bandwidth, that is, the TCP data minus any Ethernet, IP, or TCP headers. The result determines if a connection is below or above the specified threshold. For example, if a DUT is configured to prevent a connection from exceeding 2048 bytes/second, you would specify a fairness threshold of 2048. The number of connections that exceeded this throughput threshold would appear in the client realtime statistics. The default is 2147483647. •

Proxy,

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 contain 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,,Proxy, ◊


MaxTxnPerProxyConnection

Specifies the maximum transactions per connection, before the client closes the TCP connection with the proxy, regardless of whether the destination 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

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

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

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 attributes within the Network Profile should adhere to the following syntax: WaNetworkProfile,,TCPOptions, ◊


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

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.

54 |



o

TCPReceiveWindowSize

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 acknowledgements are free, in the sense that they consume no additional bandwidth. o

TCPDelayedAckTimeout

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

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

Enter a TCP Timeout value in milliseconds which will override the internally 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

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

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

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

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.

56 |



Syntax

Parameters

WaInterface,,


•

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

•


Description {}

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

Specify the subnet profile name(s) of the current subnet(s). •

Router

Router attributes within the Interface Profile should adhere to the following syntax: WaInterface,,Router, ◊


IpAddress

The outbound address of the router emulated by the interface. Use CIDR notation, that is, specify the address in dotted decimal notation. o

NetmaskBits

The number of bits in the specified network that comprise the network part of the address. o

StaticRouteTable

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

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 beginning 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,,FlatSubnet,, ◊

Iterates with each new flat subnet definition from 0 onwards. ◊


Name

Enter the baseline subnet profile name from which this flat subnet is derived. o

Offset

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 and values specified. o

Count

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 and values specified. o

Increment

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,,FlatSubnet,,UserProfile,, ◊

Iterates with each new flat subnet user profile association from 0 onwards.

58 |



◊


Name

Enter the user profile name to associate with the current flat subnet. o

Percentage

Specify the percentage load that this particular user profile will generate (from 0 - 100%). •

RouterSet

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

Iterates with each new router definition from 0 onwards. ◊


IpAddress X.X.X.X

Specify a virtual router IP address. o

NetmaskBits

Specify the virtual router’s netmask. o

StaticRouteTable

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

Specify a VLAN ID to include when InsertVlanTag is enabled. The default is 1. 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.” Interface profile RouterSet MacMasquerade attributes within the test configuration array should adhere to the following syntax: WaInterface,,RouterSet,,MacMasquerade,



◊



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 47 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 Parameters

WaSubnet,,


•

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.

•

Specify one of the following: •

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

(IPv4 only.) Enter the network address of your subnet, using CIDR notation (dotted decimal).

60 |



•

NetmaskBits

(IPv4 only.) Enter the number of bits in the network part of the address. For example, 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 configuration array should adhere to the following syntax: WaSubnet,,IpAddressRange, ◊

IpAddressRange

Enter an IP address or a range of IP addresses from which you want to generate traffic for your test ports. Use CIDR notation (dotted decimal). Alternatively, 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,,SendSide, < SendSide Parameter> ◊

ConnectionNoise

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

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

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

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

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

DelayVarianceVal2

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

ConnectionNoise

Enter the percentage of desired packets lost per million packets received. This entry emulates noisy network traffic by deliberately dropping a certain number of packets at random. The default is 0. ◊

ConnectionSpeed

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

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.

62 |



◊

EndToEndDelay

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


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

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

DelayVarianceVal2

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

IpQosValue

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


Enable or disable VLAN tagging. The default is off. •

VlanId

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 Specify the user priority for the VLAN. The valid range is 0 to 7. The default is 0.

•

VlanCFI 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,,IpFrag,



◊

Enabled on | off

Enable or disable IP Fragmentation Enable to fragment all datagrams transmitted from this subnet. The default is off. ◊

FragmentSize

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

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

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.

64 |



◊

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

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 WaStaticRouteTable), enable it via WaSubnet,,Router,Enabled, reference the appropriate routing table via WaSubnet,,Router,StaticRouteTable,, and configure this table with the default gateway address (see GatewayAddress ).

•

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

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

Iterates with each new user profile definition from 0 onward. Up to 100 user profiles per subnet are supported. ◊


Name

Specify the User Profile name.



o

Percentage

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


StaticRouteTable

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,,MacAddressRanges,

Note: You can specify only one MAC address range. ◊


MacAddressRange

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,,IPSec,

66 |



◊


Enabled on | off

o

Enable or disable IP security for this subnet. The default is off. 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 negotiate the Phase 1 Security Association (SA). ∇

Aggressive mode is used to negotiate IKE Phase 1 SAs when the protection 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.

Note: IKE operates in two different phases (Phase 1 and Phase 2) during the negotiation 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 gateways 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. ∇

o

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

IsakmpIdentification

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



o

PresharedKey

Enter the key string to use when doing Preshared key authentication. Preshared means that the parties agree on a shared, secret key that is used for authentication in an IPSec policy. o

CACertFileLocation

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

Enter the location and name of the certificate file to incorporate within the test, for example, {c:\\certs\\cert.pem}. o

PrivKeyFileLocation

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 payload data in the packets from an intelligible form (plaintext) into an unintelligible form (ciphertext), and back:

o

∇

DES: The Data Encryption Standard, defined by the U.S. government. 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.

∇


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

68 |

MD5 - A message-digest algorithm that derives a secure, irreversible, cryptographically strong hash value. This is considered less secure than SHA-1.



∇

o

SHA-1 - The Secure Hash Algorithm version one, part of the U.S. Digital Signature Standard (DSS). This algorithm is considered very secure.

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

Specify the lifetime in seconds of the Phase 1 IKE connection. The default is 28,800 seconds. o

IkeReconnThresh

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

o

∇

ESP-DES: The Data Encryption Standard, defined by the U.S. government. 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.

∇


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:

o

∇

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.

SaLdSecLife

Enter the Security Association (SA) lifetime in seconds for the established tunnel. The default is 28,800 seconds. o

RekeyThreshSecs

Enter the time limit in seconds before the Security Association (SA) lifetime expires (SaLdSecLife parameter), when a re-key for Phase 2 is started. The default is 30 seconds. o

IkeTimeout

Enter the time limit after which any Phase 1 or 2 messages will be transmitted, in seconds. o

IkeRetries

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

70 |



o

Ph2DestSubnet

Specify the destination IPv4 subnet to which ESP packets will be sent. This parameter only applies to a site-to-site tunnel. o

Ph2DestSubnetMask

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

Specify the destination IPv6 subnet to which ESP packets will be sent. This parameter only applies to a site-to-site tunnel. o

Ph2DestIp6Mask

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


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

Enter the MAC address of the local gateway. This address is only used for a site-to-site tunnel. o

LocalGwIpAddr

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 |

Enter the IP address of the remote gateway, the address to which the firewall 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,,XAuth,

Note: You must provide the XAuth attributes only when the IPSec attribute is set to XAuth. ◊


UsernameWildcardBase

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

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

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 specify this parameter along with the GroupPassword parameter for the client to interoperate with Cisco and Nortel IPSEC gateways using XAuth.

72 |



o

GroupPassword

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

Specify the profile name of the forms database, which you created using WaFormDatbase, to associate with the current subnet profile. •

ForcedPathMTU Subnet profile Forced Path MTU (maximum transmission unit) attributes within the test configuration array should adhere to the following syntax: WaSubnet,,ForcedPathMTU, ◊


Enabled on | off

Enable or disable this functionality. The default value is on. o

Size

Specify the size of the maximum transmission unit (MTU). The default is 1500 bytes. •

DHCP The dynamic host configuration protocol (DHCP) is an Internet protocol for automating 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,,Dhcp, ◊


Enabled on | off

Enable or disable DHCP mode. The default value is off. o

Timeout

Specify the amount of time in milliseconds the client waits for a response from the DHCP server. The default is 5000 milliseconds. o

Retries

Enter the number of times the client attempts to request an IP address from the DHCP server. The default is 3. o

Number

Specify the number of IP addresses to get from DHCP server. The default is 1. •

IPV6 Use the IPV6 subnet profile when configuring an IPv6 subnet. Subnet profile DHCP attributes within the test configuration array should adhere to the following syntax: WaSubnet,,IPV6, ◊


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

Specify the IPv6 prefix address to use if you enabled the AssignPrefix parameter. The default value is 3FFE::0. Use this parameter with to specify the network part of an IPv6 subnet. o

PrefixLength

Specify the IPv6 prefix length in bits, from 16 to 128. The default value is 64. Use this parameter with to specify the network part of an IPv6 subnet.

74 |



o

AddressRanges

Subnet profile AddressRanges attributes within the test configuration array should adhere to the following syntax: WaSubnet,,IPV6,AddressRanges, ∇

o

Specify two IPv6 addresses separated by a hypen (-) to indicate the IPv6 address range. The default is 3FFE::0200:FF:FE00:13FFE::0200:FF:FE00:FF.

UseMacAddress on | off Enable or disable the use of the MAC address range specified in the 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 47 Application.

Syntax Parameters

WaUserProfile,,


•

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

•

Specify one of the following: •

Description {}

Write a short sentence describing the user profile. •

Comment {}

Additional space to permit the user to place a comment.



•

ThinkTime

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

76 |



•

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

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

Specify the login name for basic authentication. •

UserPassword

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 Persistence parameter under HTTP 1.1. •

KeepAlive on | off

Enable or disable the connection after the initial request is accepted, which prevents 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 HttpProtocolLevel 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

Enter the number of transactions per connection. The default is 50.



•

NumberOfSimultaneousConnections

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

Specify one of the following: o

SSLCipherIndex

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 configure the maximum TCP connections before re-negotiation, however, the server might renegotiate before reaching that value. The default is on. o

TransactionsPerID

Enter the number of TCP connections that occur before ReuseSessionID is activated. The default is 100. The GUI equivalent for this option is the Connections Before Renegotiation field of the SSL Configuration fields. o

VerifyServer 0 | 1 | 2

Specify the required level of server authentication from the following options: 0 – No certificate checking 1 – Valid certificate optional 2 – Valid certificate mandatory The default is 0. o

CipherSuite

SSLConfig profile ciphersuite attributes within the test configuration array should adhere to the following syntax: WaUserProfile,,SSLConfig, CipherSuite,

78 |



For ing: ∇

, specify one of the follow-

Preload | 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 { } - 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

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

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,,NacProfile,Plugin,, ∇

PluginId iterates with each new Plugin definition within the cur-

rent from 0 onwards. For , specify the following: ∇

Code

A Posture Plugin (PP) provides posture credentials to a posture agent residing on the same device. Specify the Plugin code: 1—Cisco Posture Agent Plugin 2—Cisco Host Plugin 3—Cisco Anti-Virus Plugin 4—Cisco Firewall Plugin 5—Cisco Host Intrusion Protection Service (HIPS) Plugin 32768-65535—Reserved for custom plugins ∇

Name AV | FW | HIPS | Host | PA | Other Specify the name that corresponds to the Plugin code: AV (Cisco Anti-Virus Plugin) FW (Cisco Firewall Plugin) HIPS (Cisco Host Intrusion Protection Service (HIPS) Plugin) Host (Cisco Host Plugin) PA (Cisco Posture Agent Plugin) Other—Custom plugin

∇

Vid The vendor application's ID. This ID is the vendor's SMI Network Management Private Enterprise Code. The IANA (International Assigned Numbers Authority) maintains the official list of enterprise codes. Standard RADIUS attributes are associated with an ID of 0. Specify the vendor ID: 9—Cisco 311—Microsoft 0-99999—Other vendor IDs (excluding 9 and 311)

80 |



∇

Attribute

NacProfile Attribute parameters within the test configuration array should adhere to the following syntax: WaUserProfile,,NacProfile,Plugin,, Attribute,, ∇

AttributeID iterates with each new attribute definition within the

current Plugin definition from 0 onwards. For , specify the following: ∇

Id

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

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 Specify the attribute's format type (1-8) as follows:

1 = String 2 = UInt32 3 = MAC 4 = IPv4 5 = IPv6 6 = Binary 7 = Date MM/DD/YYYY HH:MM:SS 8 = Version X.X.X.X The default is 1 (String). •

UrlList

Specify the name of a URL List. Note: In the Layer 4-7 Application, you can associate a user profile and one or more URL action lists to a subnet. However, in the client, you can associate only one user profile to one URL action list. In the client, you must create a copy of the user profile each time you want to use that user profile with a different URL list.



•

UseFormData on | off

Enable or disable the use of the form database. Use a form data file to create URL lists that simulate users submitting POST requests to an Internet site. Basically, you can have a list of any variables that you want to cycle through from the URL list. For example, you might want to create a file of user names and passwords. The default is off. •

ProxyAuth on | off

Enable or disable proxy authentication. Enable to allow simulated users to log 92 in though authentication proxy servers. The client automatically hashes the username and password into the HTTP header. The default is off. •

ProxyUserName

Specify the login name for proxy authentication. •

ProxyUserPassword

Specify the login password for proxy authentication. •

MaxConnectionsPerCawUser

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

Enter a description of a simulated client’s vendor, version, and so on •

ExtendedHttpHeaders { }

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

Enter a port number to use while streaming if is set to HTTP. The default port number is 80.

82 |



•

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 . The default port number is 80.

The default is udp. •

StreamingUserAgent

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 IP address where the streaming proxy (or cache engine) is listening for streaming requests. The default is an empty string.

•

StreamingProxyPort 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

Enter the name of the user-based Load profile. •

LocalSIPPort

Enter the port number on which the SIP listener will be created. The default port is 5060. •

RTPFirstPort

Enter the port number on which the first Real-time Transport Protocol (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. •

NumOfRTPListeners

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.

84 |



•

UseDNSHostFile

Enable or disable the use of a DNS host file. If you enable the DNS Host File feature, you must also specify the DNS host file to use in the DNSHostFile parameter. 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 information.) The client will then use the host profile to map the specified host name to its IP address. The default is false. •

DNSHostFile

Enter the name of the DNS host file to use with the UseDNSHostFile parameter. •

DnsRetries

Specify the number of times a DNS query will be retried by the client. This number includes the first query attempt. The default is 3. •

DnsFirstRetryInterval

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

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

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

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

Mm4SessionTimeout

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

Mm4SystemAddress

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 information 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,,RadiusProfile, ◊

Specify the following: o

AccountingEnabled on | off

Enable or disable RADIUS accounting traffic on the corresponding UDP port. The default is on. o

UDPRetransmitCount

Specify the maximum number of times an un-acknowledged RADIUS packet may be retransmitted. The default is 10. o

UDPRetransmitInterval

Specify the time in milliseconds upon expiration of which the Authenticator must retransmit the RADIUS packet, except when the packet was already acknowledged by the Authentication Server. The default is 2000.

86 |



o

SSID

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,,RadiusProfile, Attribute,, ∇

AttributeID iterates with each new attribute definition within the

current from 0 onwards. For , specify the following: ∇

Vendor Cisco | Microsoft | Radius | Other

Specify the vendor type: Cisco Microsoft Radius Other ∇

Id

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

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 authentication traffic or RADIUS accounting traffic. The default is authentication. ∇

Value

Specify the associated RADIUS attribute value. This value should be consistent with the Format that you specify.



∇

Format Specify the attribute's format type (1-7) as follows:

1 = String 2 = UInt32 3 = MAC 4 = IPv4 5 = IPv6 6 = MTU 7 = Binary The default is 1 (String). •

BrowserPreload Firefox 1.0.3 | Firefox 1.0.4 | Ms internet explorer 5.x | Ms internet explorer 6.x | Netscape navigator 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 value of “Opera 8” will auto-populate the following parameters: , , , & . If you specify a separate value, then setting to “no” results in the use of the user-specified value. Specifying as “yes” results in the value associated with the 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.

88 |



Syntax

WaUrlList,, Example: WaUrlList, $waUrlList0Name,0 {http://192.168.42.11/ ?Transaction-Profile_cawlMconnections}

Parameters


•

Specify a name for the URL list to create.

•

Iterates with each new URL definition within the current from 0 onward. •

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 } API: {1 http://200.40.1.105 }

WaStaticRouteTable Usage

Use the static routing table profile parameters to create a static routing XML configuration file for a routed network.

Syntax

WaStaticRouteTable,,Route,,

Parameters


•

Name of the static routing XML configuration file that will be created.

•

Iterates with each new routing table entry from 0 onwards.



•

Specifies the parameter as one of the following values: •

Network

Enter the address of the network for which this routing applies. •

NetMaskBits

Enter the number of bits in the specified network that comprise the network part of the address. The default value is 24. •

GatewayAddress

Enter the address of the gateway to which you send packets destined for the specified network.

WaTelnetProfile Usage

Telnet profile entries within the test configuration array.

Syntax

WaTelnetProfile,,Telnet,

Parameters


•

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

•


options on | off

Enable or disable Open Negotiation. Enable to notify the server that before using a Telnet option, the parties must negotiate to ensure that both ends support the option. The default is on. •

endOfLineChar none | CR | CR/LF

Indicate if you want to add end-of-line characters to each Telnet command: None – No end-of-line character CR – Carriage Return CR/LF – Carriage Return and Line Feed The default is None. The GUI equivalent for this parameter is the End of Live Sequence to Send field in the Telnet Client Information fields of the Client Profiles tab.

90 |



•

Command

Telnet profile Command parameter entries within the test configuration array should adhere to the following syntax: WaTelnetProfile,,Telnet,Command,, ◊

Iterates with each new Command definition within the current from 0 onwards. ◊


send

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

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

Enter the time to wait after the send command. o

wait

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,,Telnet,ClientCommand, , ◊

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



◊


send

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

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

Enter the time to wait after the send command. o

wait

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-toPoint Protocol (PPP) parameters. The client supports the following capabilities:

• • • • • Syntax Parameters

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.

WaPPPGroupProfile,,


•

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

92 |



•


MRU

The size of the Maximum Receive Unit (MRU). The default is 1492. •

MaxConfigReq

The number of times the client sends a Configure Request message without receiving a response. The default is 3. •

MaxConfigNak

Number of times an incorrect Configure Request from the device under test (DUT) is NACKed before it is ignored. The default is 3. •

MaxTermReq

Number of times the client sends a PPP session termination message without receiving a valid acknowledgement. The default is 3. •

RestartTimer

Time in seconds between Configure Request messages. The default is 3. •

MaxLinkRetry

Number of retry attempts if negotiation of the link fails. The default is 3. •

SessionTimeout

Inactivity timeout for the PPP session. The default is 0. •

UsersPerSession

Number of simulated users per PPP session. The default is 1. •

EchoInterval 10

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 parameter of the Client Subnet Profile parameters. The client uses this information to specify the number of hosts that are in the test. The default is on. •

MagicNbr on | off

Enable or disable the automatic generation of magic number. The default is off.



•

TwoWayAuth on | off

Applies to Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP) authentication. Enables authentication in both directions simultaneously. That is, the client authenticates with the Access Concentrator (AC) using a username/password, and the AC authenticates with the client using a username/password. The client automatically accepts the username/ password supplied by the AC. If you do not enable this option, then the client performs only client authentication with the Access Concentrator (AC). The default is off. •

UseAuthDB on | off

Enable of disable the authentication option. The default is on. •

AuthType None | PAP | CHAP

Specify the type of authentication. The default is PAP. None – No authentication is performed PAP – Password Authentication Protocol CHAP – Challenge-Handshake Authentication Protocol •

DBFilename

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


WildcardUsername

Wild card username, such as user#. o

WildcardPassword

The wildcard password, such as pwd#. o

StartCountInnerLoop

Starting value of the first (inner) counter. The default is 0. o

EndCountInnerLoop

Ending value of the first (inner) counter. The default is 0. o

IncCountInnerLoop

Value by which the first (inner) counter is incremented. The default is 0. o

StartCountOuterLoop

Starting value of the second (outer) counter. The default is 0.

94 |



o

EndCountOuterLoop

Ending value of the second (outer) counter. The default is 0. o

IncCountOuterLoop

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

Parameters


•

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

•


TxRxInterval

The retry interval timer for PPPoE-related messages. The default is 3. •

MaxRetry

The number of times to retry PADI and PADR packets. The default is 3. •

ServiceName

The requested service type (string). •

ACName

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



Parameters


•

The name to assign the file in which your DDOS configuration information is stored. This information describes the traffic pattern that is generated. DDOS information is specific to a test.

•


StartingSourceMACAddress

Source Ethernet address of the first generated packet. The default is 05:00:00:00:00:01. •

StartingDestMACAddress

Destination Ethernet address of the first generated packet. The default is 0D:00:00:00:00:01. •

StartingSourceIPAddress

Source IP address of the first generated packet. The default is 192.168.10.1 •

StartingDestIPAddress

Destination IP address of the first generated packet. The default is 10.1.1.1 •

GlobalStartDelay

Delay in milliseconds between the start of the test (specifically, the beginning of its Steady State) and when DDoS attacks begin. The default is 20000. •

Arp Flood Profile Parameters

An ARPFlood attack generates ARP (Address Resolution Protocol) packets targeted at a specific network device from a range of virtual source addresses. The type of ARP packets generated (that is, ARP Request/ARP Reply) is configurable. ARPFlood attacks attempt to exploit limitations in the ARP handling/caching capabilities of target networks and network devices Arp Flood attack profile entries within the test configuration array should adhere to the following syntax: WaDDOSAttack,,ARPFlood, ◊


RepeatCount

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

PacketsToGenerate

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

96 |



o

PacketRate

The packet generation rate in packets per second. The default is 1000. o

ARPHeaderSourceEthernetAddress

The starting spoofed ARP header source Ethernet address. The default is 0A:05:00:00:00:01. o

ARPHeaderDestEthernetAddress

The ARP header destination Ethernet address of the target. The default is 0A:05:00:00:00:01. o

ARPHeaderSourceIPAddress

The starting spoofed ARP header source IP address. The default is 10.5.0.1. o

ARPHeaderDestIPAddress

The ARP header destination IP address of the target. The default is 10.13.0.1. o

ARPHeaderOperation

The ARP header operation code. The default is 2. o

LocalStartDelay

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


RepeatCount


PacketsToGenerate

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

PacketRate


UDPSourcePort

The number of the UDP header source port. The default is 1024.



o

UDPDestPort

The number of the UDP header destination port. The default is 512. o

LocalStartDelay

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


RepeatCount


PacketsToGenerate


PacketRate


TCPDestPort

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

LocalStartDelay


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,,PingOfDeath,

98 |



◊


RepeatCount


PacketsToGenerate


PacketRate


LocalStartDelay


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


RepeatCount


PacketsToGenerate


PacketRate 1000


LocalStartDelay 0


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


RepeatCount


PacketsToGenerate


PacketRate


LocalStartDelay


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


RepeatCount


PacketsToGenerate


PacketRate


TCPSourcePort

The TCP port number for the source. The default is 1024. o

TCPDestPort

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

100 |



o

LocalStartDelay


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


RepeatCount


PacketsToGenerate


PacketRate 1000


LocalStartDelay 0


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


RepeatCount

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


| 101


o

PacketsToGenerate

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

PacketRate


TCPSourcePort

The TCP header source port number. The default is 1024. o

TCPDestPort

The TCP header destination port number. The default is 80. o

LocalStartDelay


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


TargetsToHit

The number of target addresses to scan. The default is 1. o

PortsToScan

The number of ports to scan on each target. The default is 65535. o

PacketRate


TCPSourcePort

The TCP header source port number. The default is 1024. o

StartingTCPDestPort

The first TCP header destination port number to scan. The default is 0. o

LocalStartDelay

An optional delay in milliseconds between the end of the delay specified in GlobalStartDelay and when this attack begins. The default is 0.

102 |



•

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


RepeatCount


PacketsToGenerate


PacketRate


UDPSourcePort

The number of the UDP header source port. The default is 1024. o

UDPDestPort

The number of the UDP header destination port. The default is 512. o

LocalStartDelay


UDP Flood Profile Parameters A UDPFlood attack generates a sequence of UDP data packets targeted at a specific network device from a range of virtual source addresses. A UDPFlood can be used to consume network bandwidth and overwhelm the ability of networks and network devices to establish new UDP connections. UDPPortScan attacks can also be used to deplete the resources (that is, system memory) of target networks and network devices. UDP Flood attack profile entries within the test configuration array should adhere to the following syntax: WaDDOSConfig,,UDPFlood, ◊


RepeatCount

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


| 103


o

PacketsToGenerate


PacketRate


UDPSourcePort

The UDP header source port number. The default is 1024. o

UDPDestPort

The UDP header destination port number. The default is 512. o

LocalStartDelay


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


TargetsToHit

The number of target addresses to scan. The default is 1. o

PortsToScan

The number of ports to scan on each target. The default is 65535. o

PacketRate


UDPSourcePort

The UDP header source port number. The default is 1024. o

StartingUDPDestPort

The first UDP header destination port number to scan. The default is 0. o

LocalStartDelay 0


104 |



•

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


RepeatCount


PacketsToGenerate


PacketRate


UnreachableHostAddress

The IP address of the unreachable host. The default is 10.0.0.1. o

LocalStartDelay


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


RepeatCount


PacketsToGenerate

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


| 105


o

PacketRate


LocalStartDelay


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

Parameters

WaCapRepTCP,,,


•

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

•

Integer value starting at 0 iterating with each individual 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.

106 |



•

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

Enter a minimum value if an applicable action type is chosen. See Table 3-1, for a list of acceptable action types. •

Max

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


| 107


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

108 |

Action Type

Minimum and Maximum Value

expect_int8

Yes

force_send

No

forms_db

No

routing

No (This parameter is valid only for CapRepEth profiles)

send

No

send_byte

Yes

send_counter16

No

send_counter16n

No

send_counter32

No

send_counter32n

No

send_counter8

No

send_hist

No

send_int16

Yes

send_int16n

Yes

send_int32

Yes

send_int32n

Yes

send_int8

Yes

timeout

No

wait

No



Syntax2 Parameters

WaCapRepTCP,,


•


•


PcapFile

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 program. 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 specified 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) parameters are not required. (This parameter is used only when you have specified a Pcap file.) The default is false. •

DestHost

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

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


| 109


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

Parameters

WaCapRepUDP,,,


•


•


•


Type

The type of capture replay action required. See Table 3-1 on page 107, for a list of acceptable action types. •

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

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

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

110 |

WaCapRepUDP,,



Parameters


•


•


PcapFile

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 program. 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) parameters are not required. (This parameter is used only when you have specified a Pcap file.) The default is false. •

DestHost


DestPort


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.


| 111


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

Parameters

WaCapRepEth,,,


•


•


•


Type

The type of capture replay action required. See Table 3-1 on page 107, for a list of acceptable action types. •

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

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

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

First

Enter the first gateway MAC address for the client. This parameter is applicable only when the action type is “routing.”

112 |



•

Last

Enter the last gateway MAC address before the server. This parameter is applicable only when the action type is “routing.” Syntax2 Parameters

WaCapRepEth,,


•


•


PcapFile

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




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

DestHost


DestPort



| 113


WaContent Usage

Use the WaContent parameters to upload content files to the client.

Syntax

WaContent,

Parameters


•

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}

•

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

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.

114 |



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

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


Type ascii | file

Specify the type of data you want to send.


| 115


•

Body,Data

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

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

Syntax1

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. WaCookieJarList,,CookieJar,,CookieJarList


An iterative index starting at 0, incrementing with every subsequent cookie jar definition. •

CookieJarList

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,,CookieFileLocation


CookieFileLocation The full path and name of the cookie jar file to import.

116 |



Note: If you import a cookie jar file, it is renamed with the name supplied in the . You cannot add additional cookie jars to the current cookie jar profile name using the syntax shown in Syntax1.

WaHostFile Usage

Syntax1

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. WaHostFile,,Host,,


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

Specifies one of the following: ◊

Name

Specify the host name which maps to the associated IP address you specified in the IpAddress parameter. ◊

IpAddress

Enter the IP address which maps to the host name you described in the Name parameter. Syntax2

WaHostFile,,


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 .

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


| 117



The type of certificate: Authority or Revocation.

•

An iterative index starting at 0, incrementing with each new certificate file from 0 onward. •

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 and . The following example uploads two different Authority and two different Revocation certificates: WaCertificate,Authority,0 WaCertificate,Authority,1 WaCertificate,Revocation,0 WaCertificate,Revocation,1

118 |


{C:\\Certificates\\authority0.pem} {C:\\Certificates\\authority1.pem} {C:\\Certificates\\crl0.pem} {C:\\Certificates\\crl1.pem}

Chapter 3: Test Configuration Array Server Test Configuration Array Parameters

Server Test Configuration Array Parameters This section contains parameters to create and manipulate server Network, Interface, Subnet, Server, and Transaction profiles. The following parameters are described in this section:

• • • • • • • •

WrTestProfile WrNetworkProfile WrInterface WrSubnet WrStaticRouteTable WrServerProfile WrTransactionProfile WrContent


| 119


WrTestProfile Usage

Test profile entries for the server within the test configuration array.

Syntax

WrTestProfile,

Parameters


•


Description {}

Provide a description that indicates the purpose of the test. •

NetworkProfile {}

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

An integer value within the range 0 - 3, depending upon the total number of available interfaces on the server. ◊


Name {}

Specify the name of the Interface Profile to associate with the interface . o

PhysIf 0 | 1 | 2 | 3

Specify the physical port number associated with the current interface. The default is empty. o

PhysIfDisplayString

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.

120 |



•

DetailedHSC on | off

Enables or disables this detailed reporting option. This option enables you to view the cumulative HTTP status codes received by the client during a test. The default is off. •

SaveCookieJars on | off

Enables or disables cookie saving. When cookie saving is enabled, the client records all cookies transmitted during a test, enabling you to create Cookie Jar files automatically. Cookie Jar files must not exceed 64 megabytes. The default is off. •

PktTrace on | off Enables or disables the creation of a packet trace file. Enable this option if you want the server to produce a PCAP (packet capture) file in addition to its normal set of results files. The PCAP file (called trace.pcap) shows all packets sent and received, and it can be read by many standard sniffer programs, such as Ethereal, Netasyst (was Sniffer Pro), or ClearSight. The default is off.

•

PktTraceBytes The maximum size of the PCAP file in bytes. The maximum value that you can enter is 9,999,360 bytes, which is also the default.

•

UrlTrace on | off Enables or disables the creation of an XML trace file. Enable if you want an XML trace file for individual URLs, which contains errors, bindings of variables, response latency, and so on. One trace file is generated per simulated user, called httptracefile_X_trace.xml, where X is a number that represents the simulated user associated with the file. You can view this file by using the URL Trace Tool. The default is off.

•

UrlTraceOnError on | off Enable if you want only 4XX and 5XX HTTP error codes and content validation failures reported. The default is on.

WrNetworkProfile Usage

The network profile describes the TCP characteristics of your network. Use the network profile parameters to configure the server network characteristics that you want to emulate.

Syntax

WrNetworkProfile,,

Parameters


•

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


| 121


•


Description {}

Write a short sentence describing the current test. •

IpReassemblyTimeout

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


TCPMaxSegSize

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

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

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

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.

122 |



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

Enter a TCP Timeout value in milliseconds which will override the internally calculated TCP stack timeout value. This value is used if 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

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

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

Parameters


•

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

•


Description {}

Write a short sentence describing the interface profile.


| 123


•

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 connected to the port has the correct ARP cache data. The default is on. •

Subnets { }

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

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

Enter the virtual router’s netmask. o

StaticRouteTable

Specify the name of the XML file containing the static routing table. Use WrStaticRouteTable to create the static routing table. •

RouterSet

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



IpAddress X.X.X.X

Specify a virtual router IP address. o

NetmaskBits

Specify the virtual router’s netmask.

124 |



o

StaticRouteTable

Specify the name of the XML file containing the static routing table. Use WrStaticRouteTable to populate the static routing table. o


Enable or disable VLAN tagging. The default is off. o

VlanId

Specify a VLAN ID to include when InsertVlanTag is enabled. The default is 1. 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.” Interface profile RouterSet MacMasquerade attributes within the test configuration array should adhere to the following syntax: WrInterface,,RouterSet,,MacMasquerade, ◊

Iterates with each new router definition from 0 onwards.. ◊


Enabled on | off


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

Parameters


•

The name of the subnet profile to configure.

•


| 125



Description {}

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

Enter the network address of your subnet, using CIDR notation (dotted decimal). •

NetmaskBits

Enter the number of bits in the network part of the address. For example, 24 represents 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,,SendSide, ◊


ConnectionNoise

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

Enter the bits per second (bps) or link speed that a simulated user will use to connect to a network. The default is 0. o

NPacketsToDrop

Enter the number of packets to drop. When a packet must be dropped, the number of successive packets dropped is decreased by one. Any succeeding packets for that same subnet will be dropped, until the packets dropped value in the subnet becomes zero. Once this value is zero, the cycle repeats. The default is 0. o

EndToEndDelay

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.

126 |



o


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

DelayVarianceVal1

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

DelayVarianceVal2

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


ConnectionNoise

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

Enter the bits per second (bps) or link speed that a simulated user will use to connect to a network. The default is 0. o

NPacketsToDrop

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.


| 127


o

EndToEndDelay

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


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

DelayVarianceVal1

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

DelayVarianceVal2

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

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


Enable or disable VLAN tagging. The default is off. •

VlanId

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 Specify the user priority for the VLAN. The valid range is 0 to 7. The default is 0.

•

VlanCFI Specify the one-bit canonical format indicator (CFI) for the VLAN. The default is 0.

128 |



•

IpFrag

Subnet profile IpFrag attributes within the test configuration array should adhere to the following syntax: WrSubnet,,IpFrag, ◊


Enabled on | off

Enable or disable IP Fragmentation. Enable to fragment all datagrams transmitted from this subnet. The default is off. o

FragmentSize

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

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


| 129


•

MacMasquerade

Subnet profile MacMasquerade attributes within the test configuration array should adhere to the following syntax: WrSubnet,,MacMasquerade, ◊


Enabled on | off


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 WrStaticRouteTable), enable it via WrSubnet,,Router,Enabled, reference the appropriate routing table via WrSubnet,,Router,StaticRouteTable,, and configure this table with the default gateway address (see GatewayAddress ).

•

ServerProfile

Subnet profile ServerProfile attributes within the test configuration array should adhere to the following syntax: WrSubnet,,ServerProfile, , ◊

◊

Iterates with each new server profile definition from 0 onwards. Specify the parameter as one of the following values: o

Name

Specify the Server Profile name.

130 |



o

IpVersion 4 | 6

Specify the IP Version as either 4 or 6. o

IpAddressRange

Enter the IP address or range from which you want to generate traffic. o

MacAddressRange

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

Router

Router profile attributes within the test configuration array should adhere to the following syntax: WrSubnet,,Router, ◊


StaticRouteTable

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


MacAddressRange 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,,IPSec, ◊


Enabled on | off

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


| 131


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 negotiate the Phase 1 Security Association (SA).

o

∇

Aggressive mode is used to negotiate IKE Phase 1 SAs when the protection 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.

AuthMeth Preshared | RSA | XAuth

Enter the authentication method for phase 1.

o

∇

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 indicate the type of XAuth for phase 1 (Generic, Cisco, or Nortel).

IsakmpIdentification

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

PresharedKey

Enter the key string to use when doing Preshared Key authentication. Preshared means that the parties agree on a shared, secret key that is used for authentication in an IPSec policy. o

CACertFileLocation

Enter the location 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 specifed for AuthMeth is RSA.)

132 |



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

Enter the location of the certificate file to incorporate within the test, for example, {c:\\certs\\cert.pem}. o

PrivKeyFileLocation

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 payload data in the packets from an intelligible form (plaintext) into an unintelligible form (ciphertext), and back:

o

∇

DES: The Data Encryption Standard, defined by the U.S. government. 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.

∇


∇


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:

o

∇

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.

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)


| 133


The size of the group determines the level of security of the DiffieHellman 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

Enter the lifetime in seconds of the Phase 1 IKE connection. The default is 28,800 seconds. o

IkeReconnThresh

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

134 |

∇

ESP-DES: The Data Encryption Standard, defined by the U.S. government. DES is a symmetric 64-bit block cipher that uses a 56-bit key.

∇

ESP-3DES: A variant of DES, and is the most accepted method. 3DES is a combined set of two DES keys totalling 112 bits. Due to its larger size, 3DES is considered much more secure that DES.

∇

ESP-AES-128: AES (Advanced Encryption Standard) with a 128-bit key.

∇




∇ o


Ph2HashAlg MD5 | SHA-1

The hash authentication method used for Phase 2 to verify that the packets being received were sent by the stated source. Specify the hash algorithm to be used for the tunneled packets:

o

∇

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.

SaLdSecLife

Enter the Security Association (SA) lifetime in seconds for the established tunnel. The default is 28,800 seconds. o

RekeyThreshSecs

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

Enter the time limit after which any Phase 1 or 2 messages will be transmitted, in seconds. o

IkeRetries

Enter the maximum number of re-transmissions for any of the Phase 1 and Phase 2 messages. The default is 5. o

Address

Enter the subnet from which IP addresses are generated when the authentication mode is XAuth (that is, you specified XAuth for the AuthMeth parameter). o

Netmask

Enter the subnet mask for the address specified in the Address parameter (above). o

DNS

Enter the primary DNS server’s IP address for the subnet specified in the Address parameter (above). o

DNS2

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.


| 135


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


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

Enter the MAC Address of the local gateway. This is only used in a 'siteto-site' scenario. o

LocalGwIpAddr

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 |

Enter the IP Address of the remote gateway, in either IPv4 or IPv6 format. For remote-access tunnels, use the LocalGwIPVer parameter instead. •

XAuth IKE Extended Authentication (XAuth) is a protocol for authenticating user names and passwords before the tunnel is opened. Subnet profile XAuth attributes within the test configuration array should adhere to the following syntax: WrSubnet,,XAuth,

Note: You must provide the XAuth attributes only when the IPSec attribute is set to XAuth.

136 |



◊


UsernameWildcardBase

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

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:

o

∇

Generic: The default value.

∇

Cisco-EasyVPN

∇

Nortel-Contivity:

Ip6Prefix

Enter an IPv6 prefix address using colon hexadecimal notation for the XAuth network specified in Ip6MacRange. For example: Prefix Address = 3FFE::0 Interface ID = 200:FF:FE00:101-200:FF:FE00:1FF Prefix Length = 64 bits The first address in the range would be 3FFE::200:FF:FE00:101. o

Ip6Mask

Enter an IPv6 prefix length in bits, from 16 to 128 for the XAuth network specified in Ip6MacRange. o

Ip6MacRange

Specify the MAC address or range used for generating IPv6 addresses when the authentication mode is XAuth. o

Ip6DNS1

Specify the primary DNS server's IP address for the XAuth network specified in Ip6MacRange. o

Ip6DNS2

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.


| 137


•

ForcedPathMTU Subnet profile Forced Path MTU (maximum transmission unit) attributes within the test configuration array should adhere to the following syntax: WrSubnet,,ForcedPathMTU, ◊


Enabled on | off

Enable or disable this functionality. The default value is on. o

Size

Specify the size of the maximum transmission unit (MTU). The default is 1500 bytes. •

IPV6 Use the IPV6 subnet profile when configuring an IPv6 subnet. Subnet profile IPv6 attributes within the test configuration array should adhere to the following syntax: WrSubnet,,IPV6, ◊


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

Specify the IPv6 prefix address to use if you enabled the AssignPrefix parameter. The default value is 3FFE::0. Use this parameter with to specify the network part of an IPv6 subnet. o

PrefixLength

Specify the IPv6 prefix length in bits, from 16 to 128. The default value is 64. Use this parameter with 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,,IPV6,AddressRanges,

138 |



∇

o

Specify two IPv6 addresses separated by a hypen (-) to indicate the IPv6 address range. The default is 3FFE::0200:FF:FE00:13FFE::0200:FF:FE00:FF.

UseMacAddress on | off Enable or disable the use of the MAC address range specified in the 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,,Route,

Parameters


•

The name of the name of the static routing XML configuration file to create.

•

Iterates with each new routing table entry from 0 onwards.

•


Network

Enter the address of the network for which this routing table entry applies. •

NetMaskBits

Enter the number of bits in the specified network that comprise the network part of the address. •

GatewayAddress

Enter the address of the gateway to which you send packets destined for the specified network.

WrServerProfile Usage

Use the Server Profile parameters to configure information for the server protocol that you want to test.

Syntax

WrServerProfile,,


| 139


Parameters


•

The name of the server you are configuring.

•


Description {}

Provide a description of the current test. •

Port

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 ApplicationProtocol parameter and the parameter (21).

•

HTTP

HTTP server profile entries within the test configuration array should adhere to the following syntax: WrServerProfile,,HTTP, ◊


ServerType

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

If you selected HTTP 1.1, enter the maximum number of responses sent over the same TCP connection.The default is 64.

140 |



o

DefTxnProfile

Specify the transaction profile that you want to assign to this server. The default is Default. o

UpdatePct

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

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

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

Enter the maximum number of allowable cookies that the server will create. 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 transaction.


| 141


∇

o

Normal Distribution: Allows you to select a normal distribution as the means to generate an offset (time difference) from the Last Modified 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.

CookieExpiresDateTime

Specify the date and time that a cookie will expire. The format of this entry must be as follows: , For example: Thu, 06 May 2004 01:02:03 GMT. The default is an empty string. o

CookieExpiresPercent

Define the percentage of the time a server cookie will expire. The default is 0. o

CookieExpiresNormalMeanSeconds

Enter the number of seconds used as the mean number for the normal distribution This parameter is used when is set to 3. The default is 0. o

CookieExpiresNormalSDMinutes

Enter the number of seconds that the data in the distribution deviates from the mean. This parameter is used when 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 definition.) However, the functions supported are more limited: ∇

142 |

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,,SSLConfig,

Note: To instigate an HTTPS profile within a test, the parameter must be set to HTTPS. Also remember to set the parameter to 443 if configuring using default values. ◊


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.


| 143


o

AuthorityCertificate

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,,SSLConfig, CipherSuite, ◊


Cipher { | | }

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,,SMTP,

Note: To instigate this profile within a test, the parameter must be set to SMTP. Also remember to set the parameter to 25 if configuring using default values. ◊


PoTMailBoxUnavailable

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

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

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.

144 |



•

Mcast Mcast server profile entries within the test configuration array should adhere to the following syntax: WrServerProfile,,Mcast,

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


GroupAddress

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

Enter the channel increment for the group IP address (default is1). If a range is specified, then the GroupAddress Increment specifies the incremental 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

If you selected 0 (Generate dynamically) as the ContentType, enter the time, in milliseconds, between sending each packet (default is100).


| 145


o

PacketSize

If you selected Generate dynamically as the ContentType, enter the size of the packets in bytes (default is1024). o

Content

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,,Streaming,

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


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

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

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,,Telnet,

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

146 |



◊


options on | off

Enable or disable open negotiation. Enable to notify the server that before using a Telnet option, the parties must negotiate to ensure that both ends support the option. The default is on. o

endOfLineChar None CR CR/LF

Indicate if you want to add end-of-line characters to each Telnet command: None – No end-of-line character CR – Carriage Return CR/LF – Carriage Return and Line Feed The default is None. The GUI equivalent for this parameter is the End of Live Sequence to Send field in the Telnet Client Information fields of the Client Profiles tab. o

◊

Command

Telnet server profile Command parameter entries within the test configuration array should adhere to the following syntax: WrServerProfile,, Telnet, Command,, o

Command Entry Number

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

Specifies the parameter as one of the following values: ∇

send - 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 - 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 - Enter the time to wait after the send com-

mand.


| 147


∇

wait - 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 profile and should adhere to the following syntax: WrServerProfile,,DNS,Zones ◊

Zone List

A standard Tcl list (space delimited) containing the names of any defined zones (for example, { }) The second DNS server profile entry defines the zones and their associated records and should adhere to the following syntax: WrDNSZone,,Zone,

Note: To instigate a DNS profile within a test the parameter must be set to DNS. Also remember to set the 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. ◊


Name

A user-specified name for the current record. o

Type Address | MailExchange | NameServer | Pointer | Canonical |StartOfAuthority | AAAA

Specify the type of record: o

Class DNS supports only the IN (Internet) class of record. The default is 1.

o

TimeToLive Amount of time (in seconds) the resource record can be stored in cache.

o

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

148 |



o

Preference 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 Name of the designated mail server. Use this parameter when the type specified is MailExchange.

o

NameServer Name of the host machine on which the name server is running. Use this parameter when the type specified is NameServer.

o

Domain The local IP address portion of the reverse name. Use this parameter when the type specified is Pointer.

o

PrimaryName

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

The e-mail address of the person responsible for the zone. Use this parameter when the type specified is StartOfAuthority. o

SerialNumber

The serial number of the zone file. Use this parameter when the type specified is StartOfAuthority. o

RefreshInterval

The secondary refresh time. Use this parameter when the type specified is StartOfAuthority. o

RetryInterval

The secondary retry time. Use this parameter when the type specified is StartOfAuthority. o

ExpirationLimit

The secondary expire time. Use this parameter when the type specified is StartOfAuthority. o

MinimumTimeToLive

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.


| 149


MMS server profile entries within the test configuration array should adhere to the following syntax: WrServerProfile,,MMS,

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


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

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,,POP3,Mailbox, ,

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

Iterates with each new Mailbox definition from 0 onwards. ◊


User

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

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.

150 |



o

FileList,Filenumber ,

Associate a content file with a given mailbox. The parameter iterates with each associated file from 0. For example, associate two files as follows:

o

…,FileList,0

{C:\\Attachment1.txt}

…,FileList,1

{C:\\Attachment2.txt}

MinimumNumberOfMessages

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

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

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

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 Message-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,,IMAP4,NumberOfMailboxes

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


| 151


◊

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,,IMAP4,Mailbox, , ◊

◊

Iterates with each new Mailbox definition from 0 onwards.


User

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

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 mailbox, and should adhere to the following syntax: WrServerProfile,,IMAP4,Mailbox, ,Folder,, ◊

Iterates with each new Mailbox definition from 0 onwards. ◊

◊

Iterates with each new Folder definition from 0 onwards. Specifies the parameter as one of the following values: o

FolderPath

The folder name, such as “Inbox” or “Saved Messages.” o

MinimumNumberOfMessages

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

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.

152 |



o

MinimumMessageLength

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

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,,CapRepTCP,

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

◊

Iterates with each new individual action from 0 onwards.


Type

The type of capture replay action required. See Table 3-1, “Capture Replay Action Type List,” on page 107, for a list of acceptable action types. o

Value

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

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.


| 153


o

Max

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,,CapRepTCP,

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


PcapFile

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

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.

154 |



o

DestPort

Enter the port of the actual server in the capture traffic. o


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


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,,CapRepUDP,

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

Iterates with each new individual action from 0 onwards. ◊


Type

The type of capture replay action required. See Table 3-1, “Capture Replay Action Type List,” on page 107, for a list of acceptable action types. o

Value

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


| 155


o

Min

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

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,,CapRepUDP,

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


PcapFile


DestHost

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.

156 |



Note: If the resulting session closed with an RST, the client marks it successful. o

DestPort

Enter the port of the actual server in the capture traffic. o


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


•

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 Parameters If 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,,CapRepEth,

Note: To instigate this profile within a test, the parameter must be set to CapRepEth. Also remember to set the parameter to 2000 if configuring using default values. ◊


Type

The type of capture replay action required. See Table 3-1 on page 107, for a list of acceptable action types. o

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

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.


| 157


o

Max

Enter a maximum value if an applicable action type is chosen. See Table 3-1 on page 107, for a list of acceptable action types. o

First

Enter the first gateway MAC address for the client. This parameter is applicable only when the action type is “routing.” o

Last

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,,CapRepEth,

Note: To instigate this profile within a test, the parameter must be set to CapRepEth. Also remember to set the parameter to 2000 if configuring using default values. ◊


PcapFile


DestHost

Enter the IP address of the actual server in the capture traffic only if you specified a Pcap file. o

DestPort

Enter the port of the actual server in the capture traffic only if you specified a Pcap file. o


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


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.

158 |



•

SIPUDP SIP (Session Initiation Protocol) is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet 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,,SIPUdp,

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


ConnectionPort

Enter the port where the server resides. The default port is 5060. o

RTPFirstPort

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

Enter the number of RTP channels that will be created. The default is 51. 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. o

BusyCallProbability

Enter the probability (percentage) that incoming calls will be rejected by the server. The default is 0. o

EndCallTimeout

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.


| 159


o

OffHookMinTime

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

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,,SIPTcp,

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


ConnectionPort

Enter the port where the server resides. The default port is 5060. o

RTPFirstPort

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

Enter the number of RTP channels that will be created. The default is 51.

160 |



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

BusyCallProbability

Enter the probability (percentage) that incoming calls will be rejected by the server. The default is 0. o

EndCallTimeout

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

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

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 Messaging Service (MMS) Relay/Server. Each MM4 message is sent by using a separate 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,,MM4,

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


| 161


◊


OriginatorPort

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

Specify the system email address of the recipient Multimedia Messaging Service Center (MMSC). The default email address is [email protected]. o

ResponseTimeout

Specify, in milliseconds, the amount of time to wait for an MM4 response from the client. The default is 1000 milliseconds. o

MinMmscRequestTimeout

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

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

Specify, in milliseconds, the minimum delay time before sending an MM4_read_reply_report.REQ message to the client. The default is 0 milliseconds. o

MaxUserRequestTimeout

Specify, in milliseconds, the maximum delay time before sending an MM4_read_reply_report.REQ message to the client. The default is 3 milliseconds. o

DenyDeliveryReportPercentage

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

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.

162 |



o

AckDeliveryReportPercentage

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

Specify the percentage of MM4_read_reply_report.RES messages that the client sends in response to a MM4_read_reply_report.REQ received from the server. Enter a value of 0 - 100. The default is 100. •

MM4 Server Profile RequestStatusPercentage Parameters Use the MM4 server profile Request Status Percentage parameters to determine the percentage of each request status used for random selection in MM4_forward.RES. MM4 server profile RequestStatusPercentage parameter entries within the test configuration array should adhere to the following syntax: WrServerProfile,,MM4,RequestStatusPercentage,

Note: The sum of all of the following options should equal 100. ◊

Specifies the parameter (that is, request statuses) as one of the following values: o

OK

Specify the random selection percentage for “OK” as the request status used in MM4_forward.RES. The default is 100. o

Unspecified

Specify the random selection percentage for “Error-unspecified” as the request status used in MM4_forward.RES. The default is 0. o

ServiceDenied

Specify the random selection percentage for “Error-service-denied” as the request status used in MM4_forward.RES. The default is 0. o

MessageFormatCorrupt

Specify the random selection percentage for “Error-message-format-corrupt” as the request status used in MM4_forward.RES. The default is 0. o

SendingAddressUnresolved

Specify the random selection percentage for “Error-sending-address-unresolved” as the request status used in MM4_forward.RES. The default is 0. o

MessageNotFound

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


| 163


Specify the random selection percentage for “Error-network-problem” as the request status used in MM4_forward.RES. The default is 0. o

ContentNotAccepted

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

Specify the random selection percentage for “Error-unsupported-message” as the request status used in MM4_forward.RES. The default is 0. •

MM4 Server Profile MessageStatusPercentage Parameters Use the MM4 server profile Message Status Percentage parameters to determine the percentage of each message status used for random selection in MM4_delivery_report.REQ. MM4 server profile MessageStatusPercentage parameter entries within the test configuration array should adhere to the following syntax: WrServerProfile,,MM4,MessageStatusPercentage,


Specifies the parameter (that is, message statuses) as one of the following values: o

Expired

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

Retrieved

Specify the random selection percentage for “Retrieved” as the message status used in MM4_delivery_report.REQ. The default is 100. o

Deferred

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

Indeterminate

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

Forwarded

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

164 |



o

Unrecognized

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

MM4 Server Profile ReadStatusPercentage Parameters Use the MM4 server profile Read Status Percentage parameters to determine the percentage of each read status used for random selection in MM4_read_reply_report.REQ. MM4 server profile ReadStatusPercentage parameter entries within the test configuration array should adhere to the following syntax: WrServerProfile,,MM4,ReadStatusPercentage,


Specifies the parameter (that is, request statuses) as one of the following values: o

Read

Specify the random selection percentage for “Read” as the read status used in MM4_read_reply_report.REQ. The default is 100. o

DeletedWithoutBeingRead

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.


| 165


This option allows an SLB (Server Load Balancer) to match the IP address to the VIP (virtual IP address) for the server on the SLB. An HTTP client sends an HTTP request to the VIP on the SLB, and the SLB forwards the unmodified request to the same address on the server. The HTTP response from the server goes directly back to the client address specified in the unmodified HTTP request. If you enable this option, a client cannot resolve the server IP address to a MAC address. This lets the SLB handle the ARP on behalf of the server and receive IP traffic directed to the server. Without an SLB or similar device, the server cannot be reached. Important: If a server is configured to ignore ARP, all other servers at the same IP address, but with different ports, will ignore ARP. •

CloseOption Immediate | Never |AfterTimeout

Specify the method that you want the server to use to initiate an HTTP close connection. The default is Immediate. ◊

Immediate HTTP closes the TCP connection as soon as it completes all transactions for the connection. This is the default setting.

◊

Never HTTP keeps the TCP connections open. It is recommended that you do not select this checkbox. If checked, all the TCP connections remain open until the end of the test, and the system's resources will be depleted. This option is available so that network devices, such as load balancers, can be tested against the number of connections advertised by the manufacturer. Maintaining the open connection allows you to run tests using the minimum amount of bandwidth, avoiding the overhead associated with TCP connection teardown. This is the default setting.

◊

AfterTimeout HTTP waits until the time that you specify in the CloseTimeout parameter, and then it closes the connection.

Note: This option is only enabled when configuring an HTTP server (that is, = 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:

166 |

◊

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. Note: This option is only enabled when configuring an HTTP server (that is, = HTTP). •

CloseTimeout

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. Note: This option is only enabled when configuring an HTTP server (that is, = HTTP). •

ToS

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 configured as virtual routers). When enabled, GRE encapsulation is used for traffic leaving clients and servers for a given transaction. You cannot enable/disable checksums and enable/disable sequence numbers. In addition, ACK and slidingwindow 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,,

Parameters


•

The name of the HTTP/HTTPS server you are configuring.


| 167


•


Description {}

Provide a description of the current test. •

TransactionId

Enter the ID number of the transaction. The default is 1024. •

StatusCode

Enter an HTTP response status code between 100 and 599 that you want the server to send in response to requests. •

StatusPhrase

Displays the corresponding phrase for the Status Code specified in the StatusCode parameter. The default is OK. •

BodyBytes

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

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

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 average body size to vary. •

BodyString

Specify the text to embed in the HTTP response body. Use BodyString when BodyStringType is set to 2 (Fixed Text). The default is “Spirent Communications.” •

BodyStringPosition 1 | 2 | 3

Specify the position of the text in the HTTP response body. The default is 1. 1- Beginning 2- Middle 3- End

168 |



•

BodyStringRandomBytes

This feature is enabled when BodyStringType is set to 3 (Random Text). The default is 3. Its GUI equivalent is the Random Text of Length field. •

BodyStringType 1 | 2 | 3

Specify the type of text to embed in the HTTP response body. The default is 1. Its GUI equivalent is the Embedded String field 1 - Empty: Adds no embedded string in the HTTP response body. 2 - Fixed Text: The text that you enter for the BodyString parameter specifies the text to embed in the HTTP response. 3 - Random Text: Tells the server to add random text of a specified length in the response body. You enter the length in the BodyStringRandomBytes parameter. You also specify where (beginning, middle, or end) to embed the string in the HTTP response body by specifying an option for the BodyStringPosition parameter. •

ContentMD5HeaderEnabled on | off

Enable of disable Content-MD5 headers. The default is off. •

ContentMD5HeaderInterval

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

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


| 169


The delay begins after the server receives an HTTP request, for example, after a GET. The default is 0. •

LatencyMean

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

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 deviation 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 different, while a large standard deviation tells the server to generate times that are quite varied. The default is 0. •

LastModifiedHeader

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: , For example: Thu, 06 May 2004 01:02:03 GMT •

LastModifiedHeaderProgram 1 | 2 | 3

Specify the last modified header type: 1 - None: Turns off the LastModifiedHeader feature. If your test does not involve the use of cache devices, it is suggested that you specify None. 2 - Fixed: Specify a fixed timestamp that is sent on the LastModifiedHeader every time the server serves the transaction. If you specify this option, you must also specify parameter values for LastModifiedHeaderProgramStart and LastModifiedHeaderProgramEnd.

3 - Variable: Specify a range of time used for the LastModifiedHeader. Every time the server responds to a transaction, it checks the values entered here, and generates a timestamp. If you specify this option, you must also specify parameter values for: LastModifiedHeaderProgramStart (start date and time), LastModifiedHeaderProgramEnd (end date and time), LastModifiedHeaderProgramSeconds (increment amount), and LastModifiedHeaderProgramPercent (increment frequency).

170 |



The default is 1. •

LastModifiedHeaderProgramStart

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: , For example: Thu, 06 May 2004 01:02:03 GMT •

LastModifiedHeaderProgramEnd

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: , For example: Thu, 06 May 2004 01:02:03 GMT •

LastModifiedHeaderProgramSeconds

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

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

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.


| 171


3 - Uniform Distribution: If you specify this option, you must also specify parameter values for ExpiresHeaderUniformStartSeconds and ExpiresHeaderUniformEndSeconds 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 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 server uses the values specified here to create a normal distribution, which in turn is used to select an offset. •

ExpiresHeader

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: , For example: Thu, 06 May 2004 01:02:03 GMT •

ExpiresHeaderUniformStartSeconds

Determine the lower bound for the uniform distribution. The default is 1. •

ExpiresHeaderUniformEndSeconds

Determine the upper bound for the uniform distribution. The default is 1000. •

ExpiresHeaderNormalMeanSeconds

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

Determine the number of seconds that the data in the distribution deviates from the mean. The default is 1. •

BodyFilename

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

Enables you to specify a list containing different body sizes. The server uses this list as the source for body sizes.

172 |



•

BodyContentFileLocation

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

Specify the location of the file containing the HTTP Response Body Content fixed text string to be incorporated within the test, for example, {c:\\content\\string.txt}. This parameter is only used when the DataType parameter is set to 2. •

FileHierarchy

•

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

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

Specify the fully qualified path for the specified BodyFilename. A fully qualified path must begin with a forward slash (/) and include alphanumeric 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.


| 173


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

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

174 |



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


| 175


WrContent Usage

Use the Server Content Upload parameters to upload content files to the server side.

Syntax

WrContent,

Parameters


•

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}

•

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


The type of certificate: Authority or Revocation.

•

An iterative index starting at 0, incrementing with each new certificate file from 0 onward. •

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

176 |


Chapter 3: Test Configuration Array Clustered Test Configuration Array Parameters

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

Test Profile Interface Parameters Test profile entries for a clustered test within the test configuration array should adhere to the following syntax: WaTestProfile,Unit,Interface,, WrTestProfile,Unit,Interface,,

•

Unit

An integer value within the range 0 - , 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" lappend clientUnits "10.47.40.18;0" lappend clientUnits "10.47.40.17;0" lappend clientUnits "10.47.40.18;1" set clientClusterID [SPI_AV::ClusterController::CreateCluster "client" "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).

•

An integer within the range 0 - 3, depending upon the total number of available interfaces on the appliance or Spirent TestCenter chassis.


| 177

Chapter 3: Test Configuration Array Global Test Configuration Array Parameters

Global Test Configuration Array Parameters This section contains parameters that affect all devices within a test. The following parameters are described in this section:

•

Global

Global Usage

Global test profile parameters enable you to configure a system-wide delay in starting tests to compensate for link negotiation delays that may occur with your device under test (DUT). You configure parameters to be applied globally across the test, prior to running the test. These entries are equivalent to setting parameters in the Run Configure tab of the Layer 47 Application.

Syntax Parameters

Global,


•


StartTestDelay {}

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 negotiate 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 negotiation processes. You access the log file (called trace-SA.xml) by analyzing test results. You can open the test results files 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. •

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.

178 |


Chapter 3: Test Configuration Array Global 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.


| 179

180 |


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.


Clustered Functions . . . . 182

•

Query Functions . . . . 191

•

Spirent TestCenter Functions . . . . 194

•

Appliance Functions . . . . 197

•

Standard Functions . . . . 200

•

Interactive Testing Functions . . . . 212


| 181

Chapter 4: Functions Clustered Functions

Clustered Functions The following clustered functions are designed to be used in test scripts for one or more appliances or Spirent TestCenter chassis.

• • • • • • • • • • • • • • • • •

182 |

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

Syntax Parameters

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. SPI_AV::ClusterController::AbortClusteredTest

•

The unique ID of the cluster to receive the abort command Return Value Comments

1 - Abort command sent successfully 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 Syntax Parameters

Allows you to add a unit (unitID) to an existing cluster. SPI_AV::ClusterController::AddUnitToCluster

•

The unique identifier of the cluster to add

•

The unique unit IP address and unit number of the cluster to add Return Value Comments

1 - Unit successfully added to the cluster None


| 183


ClearEventLogs Description Syntax Parameters

Clears the event logs for all the units in the specified cluster. SPI_AV::ClusterController::ClearEventLogs

•

The unique identifier of the cluster from which all event logs are to be cleared Return Value Comments

None 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 Syntax

Parameters

Clears a new client or server cluster. SPI_AV::ClusterController::CreateCluster

•

Specify client to create a client-based cluster or server to create a server-based cluster

•

Specify the name of the cluster to create

•

Specify a standard Tcl list of unit IDs to incorporate into the cluster Return Value

Comments

Returns a clusterID, which is a unique identifier for the newly created cluster generated by the API None

DeleteCluster Description Syntax Parameters

Deletes an existing cluster. SPI_AV::ClusterController::DeleteCluster

•

Specify the cluster identification number of the cluster to delete

184 |



Return Value

1 - Unit successfully deleted from the cluster 0 - Problem encountered while deleting cluster

Comments

None

GenerateClusteredTest Description

Syntax

Parameters

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. SPI_AV::ClusterController::GenerateClusteredTest

•

Name of the array containing the test configuration information

•

Local directory where the newly created test is to be placed

•

Name to be given to the test being created

•

Optional, defaults to "1" Enable (1) or disable (0) Load Division on a per unit basis within the test Return Value Comments

None 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


| 185


Parameters

•

Specify the cluster identification number of the cluster to get results from

•

Specify the name of the test from which results are required

•

Location on the local machine to store the results files Return Value Comments

1 - Results successfully transferred to the specified local directory None

IsClusteredTestRunning Description Syntax

Parameters

Allows you to determine whether a specified cluster is currently running a test. SPI_AV::ClusterController::IsClusteredTestRunning

•

IP address of the device to test

•

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

Syntax

Parameters

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. SPI_AV::ClusterController::RegisterStatsCallback {filterList {}}

•

Specify the cluster identification number

•

Callback function to be called (see Comments on page 187).

186 |



•

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

Returns the callback ID of the newly created callback. The returned callbackID should be passed as an argument to UnregisterStatsCallback to unregister the callback when it is no longer required.

RemoveClusteredTest Description Syntax

Parameters

Removes the specified test from an existing cluster. SPI_AV::ClusterController::RemoveClusteredTest

•

The cluster identification number of the client or server cluster from which to remove the test

•

Unique ID (name) of the test to be removed Return Value

None

Comments

None

RemoveUnitFromCluster Description Syntax

Parameters

Removes the specified test from an existing cluster. SPI_AV::ClusterController::RemoveUnitFromCluster

•

The cluster identification number of the cluster from which to remove the unit

•

The unique unit IP address and unit number of the unit to remove from the cluster Return Value

None

Comments

None


| 187


StartClusteredTest Description Syntax

Parameters

Starts the specified cluster test. SPI_AV::ClusterController::StartClusteredTest

•

The cluster identification number of the cluster on which to start the test

•

Unique ID (name) of the test to run

•

Optional, defaults to “full” Can be “full”, “summary”, or “quick” Return Value Comments

1 - Clustered test has started successfully None

StopClusteredTest Description

Syntax Parameters

Sends a stop command to the specified cluster instructing it to stop the currently running test, perform additional cleanup, and generate statistics. SPI_AV::ClusterController::StopClusteredTest

•

The cluster identification number of the cluster running the test to stop Return Value Comments

1 - Clustered test has stopped successfully 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

Syntax

Parameters

Unregisters a previously registered callback using the callbackID returned from RegisterStatsCallback and clusterID SPI_AV::ClusterController::UnregisterStatsCallback

•

The cluster identification number of the cluster from which to unregister the callback

188 |



•

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

Syntax

Parameters

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). SPI_AV::ClusterController::UploadClusteredTest

•

The cluster identification number of the client or server cluster on which to upload the test

•

Local directory containing the test to be uploaded

•

Unique ID (name) of the test to be uploaded Return Value Comments

None The test directory specified should be the same directory as the one passed to GenerateClusteredTest.

ValidateClusteredTest Description Syntax

Parameters

Validates the specified clustered test. SPI_AV::ClusterController::ValidateClusteredTest

•

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.


| 189


•

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.

•

Unique ID (name) of the test to validate

•

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)

•

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

Syntax

Parameters

Blocks until the specified cluster completes any currently running test (that is, until the units’ test stage reaches “Stopped”). SPI_AV::ClusterController::WaitForClusteredTestCompletion

•

The cluster identification number of the cluster to block Return Value Comments

190 |

None If the cluster is already in the “Stopped” state, this function returns immediately.


Chapter 4: Functions Query Functions

Query Functions You can use the following query functions to query and modify both the API and the test configuration array for specific information.

• • • • • •

GetParameter GetProfileName GetProfileParameters GetProfileType GetValidProfileTypes SetParameter

GetParameter Description

Syntax

Parameters

Enables you to obtain one or more parameter values for a particular test configuration array. SPI_AV::GetParameter

•

Name of the test configuration array containing values you want to retrieve

•

Name of the profile or type from which to obtain the specified parameter value

•

(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 specified 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: { }.

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.


| 191


Syntax

Parameters

SPI_AV::GetProfileName

•

Name of the test configuration array containing values you want to retrieve

•

(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

Comments

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

GetProfileParameters Description Syntax Parameters

Returns a list of valid profile parameters for the specified profile type. SPI_AV::GetProfileParameter

•

Type of profile from which to obtain a parameter list (for example, WaInterface)

•

(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,,RouterSet,0,MacMasquerade,Mac0 WaInterface,,RouterSet,0,MacMasquerade,Mac1 WaInterface,,RouterSet,0,NetmaskBits WaInterface,,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

192 |

Returns a list of current profile types for the specified list of profile names.



Syntax

Parameters

SPI_AV::GetProfileType

•

Name of the test configuration array containing the profile type you want to retrieve

•

(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

Comments

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

GetValidProfileTypes Description Syntax Parameters Return Value

Comments

Returns a list of valid profile types from which you can retrieve information. SPI_AV::GetValidProfileTypes

None Returns a standard Tcl list of valid profile types (for example, WaTestProfile WaLoadProfile ...) None

SetParameter Description Syntax

Parameters

Enables you to modify a specific test configuration array parameter value. SPI_AV::SetParameter

•

Name of the test configuration array containing the value to modify

•

Name of the profile or type from which to obtain the specified parameter value

•

The parameter containing the value to modify


| 193

Chapter 4: Functions Spirent TestCenter Functions

•

The new value for the parameter to modify.

•

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 Functions Spirent TestCenter cards are segregated into a number of port groups, each containing two to three individual ports, depending on the model. Once provisioned, these port groups are reserved for your use and flagged as locked to other users. Because these cards function like standard client/server appliances, you can use the standard function calls provided by the API to interact and instantiate tests. The following functions are designed for use with Spirent TestCenter hardware to facilitate the provisioning (locking and configuration) process:

• •

CleanUp ProvisionPorts

To communicate with a locked port group, you must use the following syntax: :,

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

194 |

Removes user locks from all Spirent TestCenter ports provisioned with the ProvisionPorts command.



Syntax Parameters Return Value

SPI_AV::STC::CleanUp

None 0 – Encountered a problem 1 – Operation completed successfully

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

Syntax Parameters

Locks and configures a series of Spirent TestCenter ports so that they can be used within standard tests. SPI_AV::STC::ProvisionPorts

•

User-created standard Tcl list where each list element must adhere to the following syntax: {portId portMac portMedia portDuplex portSpeed portAutoNegotiation}

•

The location of the Spirent TestCenter port in the following format: :,

•

Specifies the MAC address the interface has been assigned via provisioning using the following syntax: XX-XX-XX-XX-XX-XX. •

Specifies the media type of the card as either copper or fiber. •

Specifies the interface duplex mode, assigned during provisioning, as one of the following: half, h, full, or f. •

Specifies the interface speed, in Mbps, assigned during provisioning, as one of the following: 10, 100, 1000, or 10000. •

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 userspecified speed or duplex setting.


| 195


Return Value

Error with message – Encountered a specific problem when attempting to provision the requested resources. 0 – Encountered a problem 1 – Operation completed successfully

Comments Example

All provisionList parameters are mandatory and must be included. 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"\ "00-00-00-00-00-a1""Copper" "Full" "100" "Disable"] lappend stcProvisionList [list "192.168.0.2:1,3" \ "00-00-00-00-00-a1""Copper" "Full" "100" "Disable"] lappend stcProvisionList [list "192.168.0.2:1,4" \ "00-00-00-00-00-a1""Copper" "Full" "100" "Disable"]

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

196 |


Chapter 4: Functions Appliance Functions

# Release all cards SPI_AV::STC::CleanUp

# Test complete puts "Test Complete"

Appliance Functions Appliances are segregated into a number of port groups or “units.” You can reserve these units for your use, in which case they are flagged as locked to other users. The following functions are designed for use with appliance hardware to facilitate the reservation process:

• •

ReserveAppUnits ReleaseAppUnits

Note: The term “unit” is used throughout this section to denote the appliance port group or CPU number, or 10GbE virtual port number.

ReserveAppUnits Description Syntax Parameters

Reserves a series of appliance units for your use when running a test. SPI_AV::Appliance::ReserveAppUnits

•

Client and server unit list adhering to the following syntax: : : ...

•

IP address of the appliance •

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

•

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 corresponding list of 2900 appliance IP address(es) that you specified in the ipAddress parameter of unitList, using the following format: ...


| 197


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

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

reserveState

0 – Not previously reserved by the same user 1 – Previously reserved by the same user If unsuccessful, returns "". Comments

At the end of the test run, all your reserved appliance units are automatically released, unless they were found to be already reserved at the start of the test (for example, via GUI reservation).

ReleaseAppUnits Description

Syntax

Parameters

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. SPI_AV::Appliance::ReleaseAppUnits

•

The reservation status list that was returned from the ReserveAppUnits command in the following format: ...

•

ipAddress

IP address of the appliance

198 |



•

unitNo

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

user

User ID in the form of @ •

reserveState

0 – Not previously reserved by the same user 1 – Previously reserved by the same user

•

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 corresponding list of 2900 appliance IP address(es) that you specified in the ipAddress parameter of previousReserveStatus, using the following format: ...

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

0 – Encountered a problem 1 – Operation completed successfully

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


| 199

Chapter 4: Functions Standard Functions

Standard Functions The following functions are designed to be used in any test script, regardless of whether it is a test for a cluster of appliances or Spirent TestCenter cards or a test for a single unit appliance or chassis:

• • • • • • • • • • • • • • • • •

200 |

AddLicense AdjustLoad CleanUp DownloadCookies Dump GetAdminConfig GetEventLog GetHostList GetInterfaceList GetLastError GetNumInterfaces GetRealTimeStats GetStatus InitializeAPI Reboot StartSNMPPolling StopSNMPPolling



AddLicense Description

Syntax

Parameters

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. SPI_AV::AddLicense | "-Demo" | -STC ...

•

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

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

Syntax

Parameters

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. SPI_AV::AdjustLoad [ []]

•

•

For an appliance, enter the IP address of the appliance. •

:,

For Spirent TestCenter, enter the IP address of the chassis, test module number (slot number), and port group number.

•


| 201


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)

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 operator to set the load to the specified integer value.

•

Optional, defaults to "" •

@ In the default case, the username and hostname environment variables, defined where the script is running, are used to form the userId.

•

Optional, defaults to 0 The index of the load profile requiring modification. The default (0) represents the “Summary” (total) for the specified unit. So, for a global load profile, you should keep the default setting. For a user-based load profile, set this index to start with 1. Note: A load index of 0 is not valid for a user-based load profile, and is ignored unless the load profile is a global load profile. The load index for a user-based load profile is determined for each unit/port group separately. The following example shows the user profile’s configArray entries for a 2500 appliance: WaUserProfile,ConnsPerSec_up1_0,LoadProfile WaUserProfile,ConnsPerSec_up2_1,LoadProfile WaUserProfile,ConnsPerSec_up3_2,LoadProfile WaUserProfile,ConnsPerSec_up4_3,LoadProfile

{ConnsPerSec_lp1}\ {ConnsPerSec_lp2}\ {ConnsPerSec_lp3}\ {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

202 |



Comments

None

CleanUp Description Syntax

Allows the API to perform cleanup operations required to exit gracefully. 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 Syntax

Parameters

Downloads all cookies created during a test. SPI_AV::DownloadCookies

•

IP address of the device or Spirent TestCenter port group ID

•

The number of the unit from which to download cookies

•

Specifies whether this test is a “client” or “server” test

•

The unique ID (or name) of the test for which you want to get cookies

•

Location on the local machine from which to download the cookies Return Value

None

Comments

None

Dump Description

Creates a debug file named “_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.


| 203


Syntax Parameters Return Value Comments

SPI_AV::Dump

None _apidump.dbg We recommend that you call this function from within a test script.

GetAdminConfig Description Syntax Parameters

Returns information regarding the current admin configuration of the specified device. SPI_AV::GetAdminConfig [] []

•


•



•

Optional, defaults to 0 The number of the unit on which the port belongs

Return Value Comments Example Return (index: value)

•


•


•


•


Returns a list of index/value pairs representing the current admin configuration. None 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

204 |



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 interfaceList,1,interfaceId: 1 modelNumber: 220 numberOfUnits: 1 osVersion: 62108 returnCode: 0 returnFiles: serialNumber: 0010f301d5ad softwareVersion: 6.2.0.30909 May 27 2004 14:09:42

GetEventLog Description

Syntax Parameters

Returns a list of index/value pairs that represent the current contents of the event log on the specified device. SPI_AV::GetEventLog [] []

•

IP address of the device or Spirent TestCenter port group ID from which to remove the test

•



•

Optional, defaults to 0 The number of the unit on which the port belongs •


•



| 205


Return Value Comments

Partial Example Return (index: value):

•


•


Returns a list of index/value pairs representing the event log. Only the last 50 messages are guaranteed to be available, although up to 100 may be returned. ...

...

...

...

...

...

...

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 Syntax Parameters

Returns information regarding the host list of the specified device. SPI_AV::GetHostList [] []

•


•



206 |



•



•


•


•


•


Returns a list of index/value pairs representing the host list. None

GetInterfaceList Description Syntax Parameters

Returns information regarding the interfaces on the specified device. SPI_AV::GetInterfaceList [] []

•


•



•



•


•


•


•


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


| 207


Example Return (index: value):

interfaceList,0,description: type:FastEth,vendor:Intel,device:82559 interfaceList,0,interfaceId: 0 interfaceList,1,description: type:FastEth,vendor:Intel,device:82559 interfaceList,1,interfaceId: 1

GetLastError Description

Syntax Parameters

Returns the last error encountered by the dispatcher process running on the specified appliance. SPI_AV::GetLastError

•

IP address of the device or Spirent TestCenter port group ID Return Value Comments

Returns the last error or exception encountered by the dispatcher process. To remove all previously stored errors, call SPI_AV::ClearEventLog.

GetNumInterfaces Description Syntax Parameters

Returns the number of interfaces that are present on the target device. SPI_AV::GetNumInterfaces

•

IP address of the device or Spirent TestCenter port group ID Return Value

None

Comments

None

GetRealTimeStats Description

Syntax Parameters

Returns the real-time statistics in their raw format (as they are received directly from the unit). SPI_AV::GetRealTimeStats []

•


208 |



•

Unit number on which the test is running

•



Return Value Comments Partial Example Return (index: value):

Returns a list of index/value pairs representing the current statistics. None 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 Syntax Parameters

Returns information detailing the status of each unit on the specified device. SPI_AV::GetStatus [] []

•


•




| 209


•


Return Value Comments Example Return (index: value):

•


•


•


•


Returns a list of index/value pairs representing the current status. None unitStatusList,0,exitCode: 0 unitStatusList,0,exitStatus: Finished unitStatusList,0,testStage: Stopped unitStatusList,0,unitNumber: 0

InitializeAPI Description Syntax Parameters Return Value

Must be called at the start of every test script to initialize the API. SPI_AV::InitializeAPI None

1 - API successfully initialized 0 - Problem encountered

Comments

None

Reboot Description Syntax Parameters

Causes the specified device to restart. SPI_AV::Reboot [] []

•

The IP address of the device or Spirent TestCenter port group ID

•

Optional, defaults to ""

210 |



•


•

Optional, defaults to 0 The number of the unit on which the port belongs •


•


•


•


Return Value

None

Comments

None


| 211

Chapter 4: Functions Interactive Testing Functions

Interactive Testing Functions Use interactive testing functions when testing against a single appliance or Spirent TestCenter card on the client and/or server side. These functions provide highly versatile functionality, from creating, uploading, and starting a test against a single appliance or card to querying the current test stage and retrieving results. The following functions are described in this section:

• • • • • • • • • • • • • • • • • •

212 |

AbortTest ClearEventLog DebugLogFile GenerateTest GetTestResults GetTestStage IsTestRunning RegisterStatsCallback RemoveTest StartSNMPPolling StopSNMPPolling StartTest StopTest UnregisterStatsCallback UploadTest ValidateTest Version WaitForTestCompletion



AbortTest Description

Syntax Parameters

Sends an abort command to the specified unit, which aborts the test immediately with no cleanup and no statistics generated. SPI_AV::AbortTest []

•


•


•




None 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 Syntax Parameters

Clears the event log for the specified device. SPI_AV::ClearEventLog [] []

•


•



•

Optional, defaults to 0


| 213


The number of the unit on which the port belongs


•


•


•


•


None 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 Syntax Parameters

Enables or disables the creation of a debug log file. SPI_AV::DebugLogFile on | off

•

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

Syntax

Parameters

Generates the test according to the information specified within the configuration array and stores it locally in the directory specified in the testDirectory parameter. SPI_AV::GenerateTest

•

Name of the array containing the test configuration information

214 |



•

Local directory where the newly created test is to be placed

•

Name to be given to the test being created

•

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

•

Optional, defaults to "4" Number of interfaces to cater for on the server side Return Value Comments

None 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

Parameters

SPI_AV::GetTestResults

•


•

Unit number to get the results from

•

Specifies whether the test is a “client” or “server” test.

•

Unique ID (name) of the test to get the results for

•

Location on the local machine to store the results files Return Value

None

Comments

None


| 215


GetTestStage Description

Syntax Parameters

Returns the test stage (that is, “ReadyToStart”, “PrepStarted”, “PrepComplete”, “RampingUp”, “SteadyState”, “RampingDown”, “Stopped”) of the specified unit. SPI_AV::GetTestStage

•


•

Unit number to get the results from Return Value Comments

Test stage of the specified unit. Exception if you encounter any problems.

IsTestRunning Description Syntax Parameters

Determines whether a test is currently running on the specified device. SPI_AV::IsTestRunning

•

IP address of the device to test or Spirent TestCenter port group ID

•

Unit number to get the results from 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

Syntax

Parameters

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. SPI_AV::RegisterStatsCallback <{filterLIst {}}>

•

IP address of the device or Spirent TestCenter ID of the port group

216 |



•

Unit number to register the callback for

•

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 Comments

Returns the callback ID of the newly created callback. 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 filterList).

•

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


| 217


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 Syntax Parameters

Removes the specified test from the unit. SPI_AV::RemoveTest

•

IP address of the device or Spirent TestCenter port group ID from which to remove the test

•

ID of the unit from which this test is to be removed

•

Specifies whether the test to remove is a “client” or “server” test

•

Unique ID (name) of the test to be removed Return Value

None

Comments

None

StartSNMPPolling Description Syntax

Parameters

Starts the SNMP Monitoring and returns the port to communicate with the SNMPpoller. SPI_AV::StartSNMPPolling

•


•

Local directory where the Tcl test and configuration files are located

•

Name of the Layer 4-7 Application’s directory in which the lib folder (with java .jar files) is located

218 |



Return Value

Comments

Returns the port number used to communicate with the SNMP poller. You use this number to stop the poller. Refer to the Layer 4-7 Application’s online Help for more about SNMP Monitoring.

StopSNMPPolling Description Syntax Parameters

Stops the SNMP Monitoring on the specified port. SPI_AV::StopSNMPPolling

•

Name of the port returned by the StartSNMPPolling function Return Value Comments

None Refer to the Layer 4-7 Application’s online Help for more about SNMP Monitoring.

StartTest Description Syntax

Parameters

Starts a specified test. SPI_AV::StartTest

•

IP address of the device or Spirent TestCenter port group ID on which to start the test

•

Unit number on which the test is to be run

•

Specifies whether the test is a “client” or “server” test

•


•

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

None

Comments

None


| 219


StopTest Description

Syntax Parameters

Sends a stop command to the specified unit instructing it to stop the currently running test, perform additional cleanup, and generate statistics. SPI_AV::StopTest []

•


•


•




None 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

Syntax

Parameters

Unregisters a previously registered callback using the callbackID returned from RegisterStatsCallback. SPI_AV::UnregisterStatsCallback

•


• Unit number for which to unregister the callback

•

ID of the callback to be unregistered Return Value

1 – Callback unregistered successfully 0 – Failed to unregister callback

220 |



Comments

None

UploadTest Description

Syntax

Parameters

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. SPI_AV::UploadTest

•


•

Unit number that this test will be uploaded for

•

Indicates whether to upload the client portion or server portion of the test (“client” or “server”)

•

Local directory containing the test to be uploaded

•

Unique ID (name) of the test to be uploaded Return Value

None

Comments

None

ValidateTest Description Syntax

Parameters

Validates a specified test. SPI_AV::ValidateTest

•

IP address of the device on which to start the test or Spirent TestCenter port group ID

•

Unit number on which the test is to be run

•

Specifies whether to run a “client” or “server” test


| 221


•


•

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 Syntax Parameters Return Value Comments

Provides the current version and build of the Scripting API. SPI_AV::Version

None Returns the current Tcl API version, for example, “Layer 4-7 TclAPI 2.10 Build 34567” None

WaitForTestCompletion Description

Syntax Parameters

Blocks until the specified unit completes any currently running test (i.e. until the units’ test stage reaches “Stopped”). SPI_AV::WaitForTestCompletion

•


•

Unit number to get the results from Return Value Comments

222 |

None If the unit is already in the “Stopped” state, this function returns immediately.


Appendix A

Statistics Message Indices In this appendix... •

Client Statistics Message Indices . . . . 224

•

Filters to Use for Client Statistics . . . . 225

•

Server Statistics Message Indices . . . . 249

•

Filters to Use for Server Statistics . . . . 250

Scripting API for Layer 4-7 Application Reference Manual

| 223

Appendix A: Statistics Message Indices Client Statistics Message Indices

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

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

For a client test running, the above filter list will cause the following indices to be present in the callbackData: timeElapsed timeRemaining pop3,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 will occur and the callback function will be passed the complete statistics message.

224 |


Appendix A: Statistics Message Indices Filters to Use for Client Statistics

Filters to Use for Client Statistics This section contains the complete list of message indices you can use when you create filters for callback functions. It also provides descriptions of these protocols:

• • • • • • • • • • • • • • • • • • • • • • •

TCP Capture-Replay UDP Capture-Replay DDOS DNS Driver FTP HTTP Load Specification Memory Miscellaneous POP3 PPP PPPoE Simulated Users SMTP Streaming TCP TCPState Telnet URL SIP IPSEC MM4

These statistics are updated at a preconfigured sampling interval. You can set the time interval with the RunTimeStatistics parameter.


| 225


TCP Capture-Replay The Client Statistics TCP Capture-Replay message indices display a summary of CaptureReplay 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.

226 |



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.


| 227


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

228 |



• ftp,unsuccessfulSessionsPerSec The number of unsuccessful 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,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: 0.


| 229


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

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

230 |



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 session (in the case of Streaming, FTP, SMTP and POP3).

• loadspec,currentLoadSpecCount The current load generation behavior over time. The load generation units displayed are those you selected when you configured the load for the test. The load units supported include Sessions, SessionsPerSecond, Connections, Connections/second, Transactions, Transactions/second and Kilobits/second.

• loadspec,desiredLoadSpecCount The desired load generation behavior over time. The load generation units displayed are those you selected when you configured the load for the test. The load units supported include Connections, ConnectionsPerSecond, Transactions, TransactionsPerSecond and Bandwidth.

• loadspec,loadSpecType The type of load being generated: Bandwidth, BodyBytes, Connections, ConnectionsPerSecond, ConnectionsPerHour, Sessions, SessionsPerSecond, SessionsPerHour, Transactions, TransactionsPerSecond, or TransactionsPerHour. This statistic returns a value of 0 - 12. Each value is described below: 0 = Bandwidth 1 = Connections 2 = Connections/second 3 = SimUsers 4 = SimUsers/second 5 = Transactions 6 = Transactions/second 7 = BodyBytes 10 = SimUsers/hour 11 = Connections/hour 12 = Transactions/hour Note: If you would like to see the text equivalent returned for the loadSpecType statistic instead of its numerical value, we recommend you add the translation to your script.


| 231


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.

232 |



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.


| 233


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

234 |



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


| 235


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

236 |



• 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 number 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 The size of the main memory pool used during the test.

• 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 The packet memory used during the test.

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.


| 237


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.

238 |



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


| 239


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

240 |



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


| 241


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

242 |



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


| 243


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

244 |



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.


| 245


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

246 |



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


| 247


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

248 |


Appendix A: Statistics Message Indices Server Statistics Message Indices

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

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

For a server test running, the above filter list will cause all pop3 indices to be present in the callbackData: pop3,abortedSessionsPerSec

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 will occur and the callback function will be passed the complete statistics message.


| 249

Appendix A: Statistics Message Indices Filters to Use for Server Statistics

Filters to Use for Server Statistics This section contains the complete list of message indices you can use when you create filters on server statistics:

• • • • • • • • • • • • • • • •

TCP Capture-Replay UDP Capture-Replay DNS Driver FTP HTTP Memory Miscellaneous POP3 SMTP Streaming TCP TCP Connections TCP State Telnet SIP

TCP Capture-Replay The Server Statistics TCP Capture-Replay message indices display a summary of Capture-Replay TCP session activity, including sessions generated per second and active 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.

250 |



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


| 251


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:

252 |

•

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 The size of the main memory pool used during the test.


| 253


• memory,mainPoolUsed The memory usage during the test, including packet memory used, main memory pool, and main memory pool size.

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

254 |



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



| 255



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

256 |



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


| 257


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.


258 |



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


| 259


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

260 |



• sip,rtpPacketsSentPerSec The number of RTP packets sent per second.

• sip,rtpPacketsRecvPerSec The number of RTP packets received per second.

MM4 The Server Statistics MM4 message indices display a summary of MM4 activity, including MM4 forward responses generated per second and various response times. These statistics show the network and/or device under test behavior when responding to a number of MM4 messages generated by the server.

• mm4,forwardResponsesSentPerSec The number of MM4 forward responses per second generated from the server and various response times.

•

mm4,deliveryReportResponseTime

The delivery report response time, which is measured from the time of sending the MM4_delivery_report.REQ message until receiving the MM4_delivery_report.RES message from the originator MMSC (Multimedia Messaging Service Center).

•

mm4,readReplyReportResponseTime

The read replay report response time, which is measured from the time of sending the the MM4_read_reply_report.REQ message until receiving the MM4_read_reply_report.RES message from the originator MMSC (Multimedia Messaging Service Center).


| 261

262 |


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


| 263

Appendix B: Sample Files Sample 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 # # # 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"]

264 |



# # Build the test configuration array # array set configArray [list \ \ _Checksum {D192C04E0215086911F6909CBA9EB20E}\ \ WaDDOSConfig,AdvDevOpenConns,Description {Global Definitions File}\ WaDDOSConfig,globaldefs,Description {Global Definitions File}\ WaDDOSConfig,PortableValidate_ConnsPerSec,Description {Global Definitions File}\ \ WaInterface,AdvDevOpenConns_inf0,Description {AdvDevOpenConns_inf0}\ WaInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquerade,Mac0 {12}\ WaInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquerade,Mac1 {22}\ WaInterface,AdvDevOpenConns_inf0,RouterSet,0,NetmaskBits {0}\ WaInterface,AdvDevOpenConns_inf0,RouterSet,0,VlanId {0}\ WaInterface,AdvDevOpenConns_inf0,Subnets {OpenConns_sn0}\ WaInterface,AdvDevOpenConns_inf1,Description {AdvDevOpenConns_inf1}\ WaInterface,AdvDevOpenConns_inf1,RouterSet,0,MacMasquerade,Mac0 {12}\ WaInterface,AdvDevOpenConns_inf1,RouterSet,0,MacMasquerade,Mac1 {22}\ WaInterface,AdvDevOpenConns_inf1,RouterSet,0,NetmaskBits {null}\ WaInterface,AdvDevOpenConns_inf1,RouterSet,0,VlanId {0}\ WaInterface,AdvDevOpenConns_inf1,Subnets {OpenConns_sn1}\


| 265


\ WaLoadProfile,OpenConns_lp,LoadSpecification {Connections}\ WaLoadProfile,OpenConns_lp,Steps,Step,0,Height

{0}\

WaLoadProfile,OpenConns_lp,Steps,Step,0,Label

{Delay}\

WaLoadProfile,OpenConns_lp,Steps,Step,0,SteadyTime {5}\ WaLoadProfile,OpenConns_lp,Steps,Step,1,Height WaLoadProfile,OpenConns_lp,Steps,Step,1,Label Up}\

{10}\ {Ramp

WaLoadProfile,OpenConns_lp,Steps,Step,1,RampTime {10}\ WaLoadProfile,OpenConns_lp,Steps,Step,1,SteadyTime {0}\ WaLoadProfile,OpenConns_lp,Steps,Step,2,Height WaLoadProfile,OpenConns_lp,Steps,Step,2,Label Step}\ WaLoadProfile,OpenConns_lp,Steps,Step,2,Num

{20}\ {Stair

{5}\

WaLoadProfile,OpenConns_lp,Steps,Step,2,Pattern {Stair}\ WaLoadProfile,OpenConns_lp,Steps,Step,2,RampTime {1}\ WaLoadProfile,OpenConns_lp,Steps,Step,2,SteadyTime {4}\ WaLoadProfile,OpenConns_lp,Steps,Step,3,Height WaLoadProfile,OpenConns_lp,Steps,Step,3,Label State}\

{0}\ {Steady

WaLoadProfile,OpenConns_lp,Steps,Step,3,Pattern {Stair}\ WaLoadProfile,OpenConns_lp,Steps,Step,3,SteadyTime {40}\ WaLoadProfile,OpenConns_lp,Steps,Step,4,Height

266 |


{0}\


WaLoadProfile,OpenConns_lp,Steps,Step,4,Label Down}\

{Ramp

WaLoadProfile,OpenConns_lp,Steps,Step,4,SteadyTime {20}\ \ WaNetworkProfile,AdvDevOpenConns,Description {Sample OpenConns}\ WaNetworkProfile,AdvDevOpenConns,Proxy,ProxyConnectionPersistence {off}\ out

WaNetworkProfile,AdvDevOpenConns,TCPOptions,TCPInactivityTime{70000}\

Get

WaNetworkProfile,AdvDevOpenConns,TCPOptions,TCPPiggyback{on}\ \

WaStaticRouteTable,StaticRoutingTable_0_0

{1}\

WaStaticRouteTable,StaticRoutingTable_0_1

{1}\

\ WaSubnet,OpenConns_sn0,Dhcp,Option60,ChildTextNode {}\ WaSubnet,OpenConns_sn0,DhcpPD,Number {255}\ WaSubnet,OpenConns_sn0,DhcpPD,Timeout {5000}\ WaSubnet,OpenConns_sn0,FlatSubnet,Count

{0}\

WaSubnet,OpenConns_sn0,IpAddressRanges,IpAddressRange {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}\ mId

WaSubnet,OpenConns_sn0,IPsec,EspTransfor{2}\

WaSubnet,OpenConns_sn0,IPsec,HashAlg {1}\


| 267


WaSubnet,OpenConns_sn0,IPsec,IkeRetries {5}\ out

WaSubnet,OpenConns_sn0,IPsec,IkeTime{5}\

WaSubnet,OpenConns_sn0,IPsec,IsakmpIdentification {ISAKMPID}\ WaSubnet,OpenConns_sn0,IPsec,IsakmpIdentificationType {2}\ WaSubnet,OpenConns_sn0,IPsec,Ph2DestSubnet {192.168.42.0}\ WaSubnet,OpenConns_sn0,IPsec,Ph2DestSubnetmask

{26}\

WaSubnet,OpenConns_sn0,IPsec,Ph2DHGroup

{0}\

WaSubnet,OpenConns_sn0,IPsec,Ph2HashAlg

{1}\

Key

WaSubnet,OpenConns_sn0,IPsec,Preshared{PRESHAREDKEY}\

WaSubnet,OpenConns_sn0,IPsec,ReKeySecs {0}\ WaSubnet,OpenConns_sn0,IPsec,RekeyThreshSecs {30}\ WaSubnet,OpenConns_sn0,IPsec,SaLdSecLife {28800}\ fix

WaSubnet,OpenConns_sn0,IPV6,AssignPre{on}\

WaSubnet,OpenConns_sn0,MacAddressRanges,MacAddressRange {00:00:00:00:01:01-00:00:00:00:01:FF}\ WaSubnet,OpenConns_sn0,MacMasquerade,Mac0 {12}\ WaSubnet,OpenConns_sn0,MacMasquerade,Mac1 {22}\ WaSubnet,OpenConns_sn0,NetmaskBits {26}\ WaSubnet,OpenConns_sn0,Network {192.168.42.0}\ WaSubnet,OpenConns_sn0,RecvSide,NPacketsToDrop {1}\ ble

268 |

WaSubnet,OpenConns_sn0,Router,StaticRouteTa{StaticRoutingTable_0_0}\



WaSubnet,OpenConns_sn0,SendSide,NPacketsToDrop {1}\ WaSubnet,OpenConns_sn0,Tunneling,LocalGwIpAddr {0.0.0.0}\ WaSubnet,OpenConns_sn0,Tunneling,LocalGwMacAddr {00:00:00:00:00:00}\ WaSubnet,OpenConns_sn0,Tunneling,Persistent {on}\ WaSubnet,OpenConns_sn0,Tunneling,RemoteGwIpAddr {0.0.0.0}\ WaSubnet,OpenConns_sn0,UdpChecksums {off}\ WaSubnet,OpenConns_sn0,UserProfile,0,Name age

{OpenConns_up_0}\

WaSubnet,OpenConns_sn0,UserProfile,0,Percent{100}\

WaSubnet,OpenConns_sn1,Dhcp,Option60,ChildTextNode {}\ WaSubnet,OpenConns_sn1,DhcpPD,Number {255}\ WaSubnet,OpenConns_sn1,DhcpPD,Timeout {5000}\ WaSubnet,OpenConns_sn1,FlatSubnet,Count

{0}\

WaSubnet,OpenConns_sn1,IpAddressRanges,IpAddressRange {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}\ mId

WaSubnet,OpenConns_sn1,IPsec,EspTransfor{2}\

WaSubnet,OpenConns_sn1,IPsec,HashAlg {1}\ WaSubnet,OpenConns_sn1,IPsec,IkeRetries {5}\ out

WaSubnet,OpenConns_sn1,IPsec,IkeTime{5}\

WaSubnet,OpenConns_sn1,IPsec,IsakmpIdentification {ISAKMPID}\


| 269


WaSubnet,OpenConns_sn1,IPsec,IsakmpIdentificationType {2}\ WaSubnet,OpenConns_sn1,IPsec,Ph2DestSubnet {192.168.42.64}\ WaSubnet,OpenConns_sn1,IPsec,Ph2DestSubnetmask

{26}\

WaSubnet,OpenConns_sn1,IPsec,Ph2DHGroup

{0}\

WaSubnet,OpenConns_sn1,IPsec,Ph2HashAlg

{1}\

Key

WaSubnet,OpenConns_sn1,IPsec,Preshared{PRESHAREDKEY}\

WaSubnet,OpenConns_sn1,IPsec,ReKeySecs {0}\ WaSubnet,OpenConns_sn1,IPsec,RekeyThreshSecs {30}\ WaSubnet,OpenConns_sn1,IPsec,SaLdSecLife {28800}\ fix

WaSubnet,OpenConns_sn1,IPV6,AssignPre{on}\

WaSubnet,OpenConns_sn1,MacAddressRanges,MacAddressRange {00:00:00:00:01:01-00:00:00:00:01:FF}\ WaSubnet,OpenConns_sn1,MacMasquerade,Mac0 {12}\ WaSubnet,OpenConns_sn1,MacMasquerade,Mac1 {22}\ WaSubnet,OpenConns_sn1,NetmaskBits {26}\ WaSubnet,OpenConns_sn1,Network {192.168.42.64}\ WaSubnet,OpenConns_sn1,RecvSide,NPacketsToDrop {1}\ ble

WaSubnet,OpenConns_sn1,Router,StaticRouteTa{StaticRoutingTable_0_1}\

WaSubnet,OpenConns_sn1,SendSide,NPacketsToDrop {1}\ WaSubnet,OpenConns_sn1,Tunneling,LocalGwIpAddr {0.0.0.0}\ WaSubnet,OpenConns_sn1,Tunneling,LocalGwMacAddr {00:00:00:00:00:00}\

270 |



WaSubnet,OpenConns_sn1,Tunneling,Persistent {on}\ WaSubnet,OpenConns_sn1,Tunneling,RemoteGwIpAddr {0.0.0.0}\ WaSubnet,OpenConns_sn1,UdpChecksums {off}\ WaSubnet,OpenConns_sn1,UserProfile,0,Name age

{OpenConns_up_1}\

WaSubnet,OpenConns_sn1,UserProfile,0,Percent{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,Interface,0,PhysIf

{0}\

WaTestProfile,Unit0,Interface,1,Name {AdvDevOpenConns_inf1}\ WaTestProfile,Unit0,Interface,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}\ \ ers

WaUserProfile,OpenConns_up_0,ExtendedHttpHead{}\

WaUserProfile,OpenConns_up_0,HttpProtocolLevel {1}\ WaUserProfile,OpenConns_up_0,MaxConnectionsPerCawUser {}\ WaUserProfile,OpenConns_up_0,Persistence {off}\


| 271


WaUserProfile,OpenConns_up_0,SSLConfig,CipherSuite,Cipher {{}}\ WaUserProfile,OpenConns_up_0,SSLConfig,Versions {{}}\ WaUserProfile,OpenConns_up_0,UrlList {OpenConns_act0}\ ies

WaUserProfile,OpenConns_up_0,UseCook{off}\

ers

WaUserProfile,OpenConns_up_1,ExtendedHttpHead{}\

WaUserProfile,OpenConns_up_1,HttpProtocolLevel {1}\ WaUserProfile,OpenConns_up_1,MaxConnectionsPerCawUser {}\ WaUserProfile,OpenConns_up_1,Persistence {off}\ WaUserProfile,OpenConns_up_1,SSLConfig,CipherSuite,Cipher {{}}\ WaUserProfile,OpenConns_up_1,SSLConfig,Versions {{}}\ WaUserProfile,OpenConns_up_1,UrlList {OpenConns_act1}\ ies

WaUserProfile,OpenConns_up_1,UseCook{off}\ \

WrInterface,AdvDevOpenConns_inf0,Description {AdvDevOpenConns_inf0}\ WrInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquerade,Mac0 {12}\ WrInterface,AdvDevOpenConns_inf0,RouterSet,0,MacMasquerade,Mac1 {22}\ WrInterface,AdvDevOpenConns_inf0,RouterSet,0,NetmaskBits {0}\ WrInterface,AdvDevOpenConns_inf0,RouterSet,0,VlanId {0}\ WrInterface,AdvDevOpenConns_inf0,Subnets {echo_sn0}\ WrInterface,AdvDevOpenConns_inf1,Description {AdvDevOpenConns_inf1}\ WrInterface,AdvDevOpenConns_inf1,RouterSet,0,MacMasquerade,Mac0 {12}\

272 |



WrInterface,AdvDevOpenConns_inf1,RouterSet,0,MacMasquerade,Mac1 {22}\ WrInterface,AdvDevOpenConns_inf1,RouterSet,0,NetmaskBits {null}\ WrInterface,AdvDevOpenConns_inf1,RouterSet,0,VlanId {0}\ WrInterface,AdvDevOpenConns_inf1,Subnets {echo_sn1}\ \ WrNetworkProfile,AdvDevOpenConns,Description {Sample echo}\ out

WrNetworkProfile,AdvDevOpenConns,TCPOptions,TCPInactivityTime{70000}\

WrNetworkProfile,AdvDevOpenConns,TCPOptions,TCPRetries {5}\ \ col

WrServerProfile,HTTPServer,ApplicationProto{HTTP}\

WrServerProfile,HTTPServer,Description {Sample echo}\ WrServerProfile,HTTPServer,HTTP,ServerType {Microsoft-IIS/6.0}\ WrServerProfile,HTTPServer,Port {80}\ \ WrStaticRouteTable,StaticRoutingTable_0_0

{1}\

WrStaticRouteTable,StaticRoutingTable_0_1

{1}\

\ WrSubnet,echo_sn0,IpFrag,PacketsPerMillion {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}\


| 273


WrSubnet,echo_sn0,IPsec,DNS2 {0.0.0.0}\ WrSubnet,echo_sn0,IPsec,EncAlg {1}\ mId

WrSubnet,echo_sn0,IPsec,EspTransfor{2}\

WrSubnet,echo_sn0,IPsec,HashAlg {1}\ WrSubnet,echo_sn0,IPsec,IkeRetries {5}\ WrSubnet,echo_sn0,IPsec,IkeTimeout {5}\ WrSubnet,echo_sn0,IPsec,IsakmpIdentification {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,RekeyThreshSecs {30}\ WrSubnet,echo_sn0,IPsec,SaLdSecLife {28800}\ WrSubnet,echo_sn0,IPV6,AssignPrefix {on}\ WrSubnet,echo_sn0,MacAddressRanges,MacAddressRange {00:00:00:00:01:01-00:00:00:00:01:FF}\ WrSubnet,echo_sn0,MacMasquerade,Mac0 {12}\ WrSubnet,echo_sn0,MacMasquerade,Mac1 {22}\ WrSubnet,echo_sn0,Network {192.168.42.0}\ WrSubnet,echo_sn0,RecvSide,NPacketsToDrop {1}\ ble

WrSubnet,echo_sn0,Router,StaticRouteTa{StaticRoutingTable_0_0}\

WrSubnet,echo_sn0,SendSide,NPacketsToDrop {1}\

274 |



WrSubnet,echo_sn0,ServerProfile,0,IpAddressRange {192.168.42.11}\ WrSubnet,echo_sn0,ServerProfile,0,Name

{HTTPServer}\

WrSubnet,echo_sn0,Tunneling,LocalGwIpAddr {0.0.0.0}\ WrSubnet,echo_sn0,Tunneling,LocalGwMacAddr {00:00:00:00:00:00}\ WrSubnet,echo_sn0,Tunneling,Persistent {on}\ WrSubnet,echo_sn0,Tunneling,RemoteGwIpAddr {0.0.0.0}\ WrSubnet,echo_sn0,UdpChecksums {off}\ WrSubnet,echo_sn0,VlanId {1}\ WrSubnet,echo_sn1,IpFrag,PacketsPerMillion {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}\ mId

WrSubnet,echo_sn1,IPsec,EspTransfor{2}\

WrSubnet,echo_sn1,IPsec,HashAlg {1}\ WrSubnet,echo_sn1,IPsec,IkeRetries {5}\ WrSubnet,echo_sn1,IPsec,IkeTimeout {5}\ WrSubnet,echo_sn1,IPsec,IsakmpIdentification {ISAKMPID}\ WrSubnet,echo_sn1,IPsec,Netmask {255.255.255.0}\


| 275


WrSubnet,echo_sn1,IPsec,Ph2DHGroup {0}\ WrSubnet,echo_sn1,IPsec,Ph2HashAlg {1}\ WrSubnet,echo_sn1,IPsec,PresharedKey {PRESHAREDKEY}\ WrSubnet,echo_sn1,IPsec,RekeyThreshSecs {30}\ WrSubnet,echo_sn1,IPsec,SaLdSecLife {28800}\ WrSubnet,echo_sn1,IPV6,AssignPrefix {on}\ WrSubnet,echo_sn1,MacAddressRanges,MacAddressRange {00:00:00:00:01:01-00:00:00:00:01:FF}\ WrSubnet,echo_sn1,MacMasquerade,Mac0 {12}\ WrSubnet,echo_sn1,MacMasquerade,Mac1 {22}\ WrSubnet,echo_sn1,Network {192.168.43.0}\ WrSubnet,echo_sn1,RecvSide,NPacketsToDrop {1}\ ble

WrSubnet,echo_sn1,Router,StaticRouteTa{StaticRoutingTable_0_1}\

WrSubnet,echo_sn1,SendSide,NPacketsToDrop {1}\ WrSubnet,echo_sn1,ServerProfile,0,IpAddressRange {192.168.43.11}\ WrSubnet,echo_sn1,ServerProfile,0,Name

{HTTPServer}\

WrSubnet,echo_sn1,Tunneling,LocalGwIpAddr {0.0.0.0}\ WrSubnet,echo_sn1,Tunneling,LocalGwMacAddr {00:00:00:00:00:00}\ WrSubnet,echo_sn1,Tunneling,Persistent {on}\ WrSubnet,echo_sn1,Tunneling,RemoteGwIpAddr {0.0.0.0}\ WrSubnet,echo_sn1,UdpChecksums {off}\ WrSubnet,echo_sn1,VlanId {1}\

276 |



\ WrTestProfile,Description {Advanced Generic Device Test}\ WrTestProfile,Name {AdvDevOpenConns}\ WrTestProfile,NetworkProfile {AdvDevOpenConns}\ WrTestProfile,Unit0,Interface,0,Name {AdvDevOpenConns_inf0}\ WrTestProfile,Unit0,Interface,0,PhysIf

{0}\

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

{1}\

\ WrTransactionProfile,caw1Mconnections,BodyBytes {8}\ WrTransactionProfile,caw1Mconnections,BodyFileName {Default}\ WrTransactionProfile,caw1Mconnections,BodyString {Spirent Comm 1kBytes with 60 sec delay}\ WrTransactionProfile,caw1Mconnections,BodyStringRandomBytes {100}\ WrTransactionProfile,caw1Mconnections,DataType

{2}\

WrTransactionProfile,caw1Mconnections,Description {60 sec delay 1k Bytes for 1Million connections}\ WrTransactionProfile,caw1Mconnections,ExpiresHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,caw1Mconnections,ExpiresHeaderProgram {2}\ ers

WrTransactionProfile,caw1Mconnections,ExtendedHttpHead{}\

WrTransactionProfile,caw1Mconnections,LastModifiedHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,caw1Mconnections,LastModifiedHeaderProgram {2}\ WrTransactionProfile,caw1Mconnections,LastModifiedHeaderProgramEnd {Mon, 29 Jan 2001 23:59:59 GMT}\


| 277


WrTransactionProfile,caw1Mconnections,LastModifiedHeaderProgramStart {Mon, 01 Jan 2001 00:00:01 GMT}\ WrTransactionProfile,caw1Mconnections,Latency

{60000}\

WrTransactionProfile,caw512k,BodyBytes {512000}\ WrTransactionProfile,caw512k,BodyString {Spirent Comm 512kByte response}\ WrTransactionProfile,caw512k,BodyStringRandomBytes {100}\ WrTransactionProfile,caw512k,Description {512kByte response}\ WrTransactionProfile,caw512k,ExpiresHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,caw512k,ExpiresHeaderProgram {2}\ ers

WrTransactionProfile,caw512k,ExtendedHttpHead{}\

WrTransactionProfile,caw512k,LastModifiedHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,caw512k,LastModifiedHeaderProgram {2}\ WrTransactionProfile,caw512k,LastModifiedHeaderProgramEnd {Mon, 29 Jan 2001 23:59:59 GMT}\ WrTransactionProfile,caw512k,LastModifiedHeaderProgramStart {Mon, 01 Jan 2001 00:00:01 GMT}\ WrTransactionProfile,Data,AsciiTextFileLocation {./files/transactionbodycontent/Data.bin}\ WrTransactionProfile,Data,BodyBytes {1024}\ WrTransactionProfile,Data,BodyStringRandomBytes {100}\ WrTransactionProfile,Data,DataType {1}\ WrTransactionProfile,Data,Description {Data}\ WrTransactionProfile,Data,ExpiresHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,Data,ExpiresHeaderProgram {2}\ ers

278 |

WrTransactionProfile,Data,ExtendedHttpHead{}\



WrTransactionProfile,Data,LastModifiedHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,Data,LastModifiedHeaderProgram {2}\ WrTransactionProfile,Data,LastModifiedHeaderProgramEnd {Mon, 29 Jan 2001 23:59:59 GMT}\ WrTransactionProfile,Data,LastModifiedHeaderProgramStart {Mon, 01 Jan 2001 00:00:01 GMT}\ WrTransactionProfile,Default,BodyBytes {64}\ WrTransactionProfile,Default,BodyStringPosition {2}\ WrTransactionProfile,Default,BodyStringRandomBytes {100}\ WrTransactionProfile,Default,Description {Default Server}\ WrTransactionProfile,Default,ExpiresHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,Default,ExpiresHeaderProgram {2}\ ers

WrTransactionProfile,Default,ExtendedHttpHead{}\

WrTransactionProfile,Default,LastModifiedHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,Default,LastModifiedHeaderProgram {2}\ WrTransactionProfile,Default,LastModifiedHeaderProgramEnd {Mon, 29 Jan 2001 23:59:59 GMT}\ WrTransactionProfile,Default,LastModifiedHeaderProgramStart {Mon, 01 Jan 2001 00:00:01 GMT}\ WrTransactionProfile,Delay,AsciiTextFileLocation {./files/transactionbodycontent/Delay.bin}\ WrTransactionProfile,Delay,BodyBytes {64}\ WrTransactionProfile,Delay,BodyStringRandomBytes {100}\ WrTransactionProfile,Delay,DataType {1}\ WrTransactionProfile,Delay,Description {Delay}\ WrTransactionProfile,Delay,ExpiresHeader {Thu, 01 Jan 1970 00:00:17 GMT}\


| 279


ers

WrTransactionProfile,Delay,ExtendedHttpHead{}\

WrTransactionProfile,Delay,LastModifiedHeader {Thu, 01 Jan 1970 00:00:17 GMT}\ WrTransactionProfile,Delay,LastModifiedHeaderProgramEnd {Mon, 29 Jan 2001 23:59:59 GMT}\ WrTransactionProfile,Delay,LastModifiedHeaderProgramStart {Mon, 01 Jan 2001 00:00:01 GMT}\ WrTransactionProfile,Delay,Latency {5000}\ ]

280 |


Appendix B: Sample Files Sample Test Script

Sample Test Script The contents of the test.tcl script is as follows: ###################################################################### #### # # GUI2Script Generated Test # ###################################################################### #### # # COMMANDER INFO # - Originating Test Name

: AdvDevOpenConns

# - Originating Project Name : Validation # ###################################################################### #### # Script Created: 2007/08/27 11:58:19 ###################################################################### ####

# # Initialization of user boolean(s) # set bEnableLogging 0; # Enable (1) to create a log file for enhanced debugging

# # Initialization of status boolean(s) # set bTestActive 0

# # Define a Client callback procedure # proc clientStatsCallbackProc {clusterID data} { array set dataArray $data


| 281


catch { puts "Client Attempted

: $dataArray(http,attemptedTxns)"

puts "Client Successful

: $dataArray(http,successfulTxns)"

puts "Client Unsuccessful : $dataArray(http,unsuccessfulTxns)" puts "Client Aborted puts "\tTIME (seconds)

: $dataArray(http,abortedTxns)" Elapsed


puts "\t\t\tRemaining : $dataArray(timeRemaining)" } puts "" }

# # Define a Server callback procedure # proc serverStatsCallbackProc {clusterID data} { array set dataArray $data

catch { puts "Server Per second

: $dataArray(tcpConn,connsPerSec)"

puts "Server Open

: $dataArray(tcpConn,openConns)"

puts "Server Closed with error : $dataArray(tcpConn,closedWithError)" puts "Server Closed with reset : $dataArray(tcpConn,closedWithReset)" puts "Server Closed no error Error)"

: $dataArray(tcpConn,closedWithNo-

puts "\tTIME (seconds)


Elapsed

} puts "" }

if {[catch { # # Load the SPI_AV package #

282 |



set auto_path [linsert $auto_path 0 "C:/Program Files/Spirent Communications/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"


| 283


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

284 |



SPI_AV::ClusterController::StopClusteredTest $clientClusterID SPI_AV::ClusterController::WaitForClusteredTestCompletion $clientClusterID puts " - done"

puts -nonewline "Stopping Server Cluster"; flush stdout SPI_AV::ClusterController::StopClusteredTest $serverClusterID SPI_AV::ClusterController::WaitForClusteredTestCompletion $serverClusterID 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"


| 285


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

# 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 $clientClusterID puts " - done"

286 |



# # 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 $serverClusterID 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 $clientClusterID $testId [file join $resultsDirectory] puts " - done"

puts -nonewline "Transferring Server Cluster Results"; flush stdout SPI_AV::ClusterController::GetClusteredTestResults $serverClusterID $testId [file join $resultsDirectory] puts " - done"

} catchError]} { puts "An exception occurred: $catchError" puts "ErrorInfo:" puts "$::errorInfo"

if {$bTestActive} { catch {SPI_AV::ClusterController::AbortClusteredTest $clientClusterID} catch {SPI_AV::ClusterController::AbortClusteredTest $serverClusterID} }


| 287


# 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 $clientClusterID $clientStatsCallbackID} catch {SPI_AV::ClusterController::UnregisterStatsCallback $serverClusterID $serverStatsCallbackID}

catch {SPI_AV::STC::CleanUp} catch {SPI_AV::CleanUp}

puts "Done!"

288 |


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


| 289

Appendix C: Troubleshooting Scripts Troubleshooting Common Problems

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

Check your environment Error message: tDOM wasn’t compile for multithreading. Check to be sure you have the correct version of ActiveTcl: 1

Open a new window. If you are using Windows, choose Run from the Start menu, and enter CMD.

2

Check your ActiveTcl version (for example, type c:\tclshl).

3

At the Tcl prompt (%), type info patchlevel, and press Enter to see the Tcl version you are running. Refer to the Release Notes for the correct version of Tcl to use for the current release.

4

Type package require tdom, and press Enter. It should return 080 or higher.

5

Type package require tbcload, and press Enter. It should return 1.3 or higher.

Check your debug logs The Scripting API for the Layer 4-7 Application, provides debug logs to help you determine the cause of the problem. In a Windows environment, you can open the .dbg log using WinZip. To open a .dbg file on Linux and Solaris environments, you must use gunzip and untar. If your SPI_AV::Dump function created a <script_name>_apidump.dbg file, you must first rename the .dbg file with a “.gz” extension so that you can then gunzip and then untar it to see its contents, which include the debug and event log files. Follow these steps to unzip and untar the <script_name>_apidump.dbg file: 1 2

Rename the <script_name>_apidump.dbg file and change its .dbg extension to .gz as follows: # mv <script_name>_apidump.dbg <script_name>_apidump.gz 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.

290 |



Warning: Dispatcher::startClient failed: Failed to start Client or WARNING: Dispatcher::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 _apidump.dbg file back to Spirent for further analysis. The _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=“//Spirent_TestCenter_2.xx/ Layer_4_7_Application_Solaris/STC:// 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.


| 291


bash: export SPIRENT_TCLAPI_ROOT=/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 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.

292 |


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


| 293

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.

Optional resistor

ESD protective surface or mat

Wrist strap ESD protective floor mat (optional)

Figure D-1. ESD Protected Workstation

Note: The equipment needed for proper grounding is available in ESD service kits, such as the ESD Field Service Kit available from Spirent Communications (P/N 170-1800). Additional information on ESD can be found on the following website: http://www.esda.org/aboutesd.html

294 |


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.


| 295

296 |


Index A AbortClusteredTest function 183 AddLicense function 201 AddUnitToCluster function 183 AdjustLoad function 201 Avalanche appliance software upgrading 18 C cleaning guidelines, fiber optics 295 CleanUp function 194, 197, 203 ClearEventLog function 213 ClearEventLogs function (cluster) 184 Clustered Parameters 177 configuration array modifying 24, 25, 26 CreateCluster function 184 D DebugLogFile function 214 DeleteCluster function 184 DownloadCookies function 203 Dump function 203 E equipment handling ESD service kits 294 preparing your workstation 294 ESD requirements 293 F functions 191, 194, 197, 200, 212 Clustered AbortClusteredTest 183 AddUnitToCluste 183 ClearEventLogs (cluster) 184 CreateCluster 184 DeleteCluster 184 GenerateClusteredTest 185 GetClusteredTestResults 185 IsClusteredTestRunning 186 RegisterStatsCallback (cluster) 186 RemoveClusteredTest 187 RemoveUnitFromCluster 187 StartClusteredTest 188 StopClusteredTest 188

UnregisterStatsCallback 188 UploadClusteredTest 189 ValidateClusteredTest 189 WaitForClusteredTestCompletion 190 Interactive Testing ClearEventLog 213 DebugLogFile 214 GenerateTest 214 GetTestResults 215 GetTestStage 216 IsTestRunning 216 RegisterStatsCallback 216 RemoveTest 218 StartSNMPPolling 218 StartTest 219 StopSNMPPolling 219 StopTest 220 UnregisterStatsCallback 220 UploadTest 221 ValidateTest 221 Version 222 WaitForTestCompletion 222 Query GetParameter 191 GetProfileName 191 GetProfileParameters 192 GetProfileType 192 GetValidProfileType 193 SetParameter 193 Spirent TestCenter CleanUp 194, 197 ProvisionPorts 195, 198 Standard AddLicense 201 AdjustLoad 201 CleanUp 203 DownloadCookies 203 Dump 203 GetAdminConfig 204 GetEventLog 205 GetHostList 206 GetInterfaceList 207 GetLastError 208 GetNumInterfaces 208 GetRealTimeStats 208 GetStatus 209


| 297

Index

InitializeAPI 210 Reboot 210 G GenerateClusteredTest function 185 GenerateTest function 214 GetAdminConfig function 204 GetClusteredTestResults function 185 GetEventLog function 205 GetHostList function 206 GetInterfaceList function 207 GetLastError function 208 GetNumInterfaces function 208 GetParameter function 191 GetProfileName function 191 GetProfileParameters function 192 GetProfileType function 192 GetRealTimeStats function 208 GetStatus function 209 GetTestResults function 215 GetTestStage function 216 GetValidProfileType function 193 Global test profile 178 H hardware requirements Spirent TestCenter chassis 9 I InitializeAPI function 210 installation hardware 9 Interactive Testing functions 212 IsClusteredTestRunning function 186 IsTestRunning function 216 J Java installing 14 M messages printing results 37 N notation conventions reference manual 8 P profile server 139 user 75 ProvisionPorts function 195, 198 Q Query functions 191

298 |


R Reboot function 210 RegisterStatsCallback function 216 RegisterStatsCallback function (cluster) 186 RemoveClusteredTest function 187 RemoveTest function 218 RemoveUnitFromCluster function 187 requirements electrostatic discharge 293 S sample test script modifying 28 Scripting API configuring a test 20 installing 15 running a test 20 supported functionality 17 scripts debugging 38 modifying 28 Server Content Upload Parameters 176 server profile 139 SetParameter function 193 Spirent TestCenter chassis support 9 hardware requirements 9 modifying a configuration array for 26 test configuration array 26 Spirent TestCenter functions 194, 197 Standard functions 200 StartClusteredTest function 188 StartSNMPPolling function 218 StartTest function 219 statistics displaying 37 StopClusteredTest function 188 StopSNMPPolling function 219 StopTest function 220 T test configuration array Avalanche/Client parameters 41, 178 Clustered parameters 177 clustered parameters 177 Global 178 modifying 24, 25, 26 profile entry format 40 rReflector/Server parameters 119 samples 21 test profile parameters 177 Transaction Profile 167 WaCapRepEth 111 WaCapRepTCP 106 WaCapRepUDP 109 WaCertificate 117, 176 WaContent 114 WaDDOSConfig 95

Index

WaFormDatabase 114 WaHostFile 117 WaHttpContent 115, 116 WaInterface 56 WaLoadProfile 45 WaNetworkProfile 52 WaPPPGroupProfile 92 WaPPPoEGroupParams 95 WaStaticRouteTable 89 WaSubnet 60 WaTelnetProfile 90 WaTestProfile 42 WaUrlList 88 WaUserProfile 75 WrContent 176 WrInterface 123 WrNetworkProfile 121 WrServerProfile 139 WrStaticRouteTable 139 WrSubnet 125 WrTestProfile 120 test results collecting 37 printing 37 test scripts debugging 38 samples 21 tests samples included with API 24 Transaction Profile 167

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

U UnregisterStatsCallback function 220 UnregisterStatsCallback function (cluster) 188 Upgrading appliance software 18 UploadClusteredTest function 189 UploadTest function 221 user profile 75 V ValidateClusteredTest function 189 ValidateTest function 221 Version function 222 W WaCapRepEth 111 WaCapRepTCP 106 WaCapRepUDP 109 WaCertificate 117, 176 WaContent 114 WaDDOSConfig 95 WaFormDatabase 114 WaHostFile 117 WaHttpContent 115, 116 WaInterface 56 WaitForClusteredTestCompletion function 190 WaitForTestCompletion function 222 WaLoadProfile 45


| 299

L4 7 Scripting API

Recommend Documents