t cl development guide

Ixia TclDevelopment Guide

Release 3.50

Part No. 909-0003 Rev BFebruary 5, 2002

ii Ixia Tcl Development Guide

Copyright © 1998-2/5/02 Ixia. All rights reserved.

Ixia and its licensors retain all ownership rights to the IXIA 100, 400 and 1600 hardware and software and its doc-umentation. Use of Ixia hardware and software is governed by the license agreement accompanying your original purchase. This manual, as well as the hardware and software described in it, is furnished under license and may only be used or copied in accordance with the terms of such license. The information in this manual is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Ixia. Ixia assumes no responsibility or liability for any errors or inaccuracies that may appear in this book.Except as permitted by such license, no part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written permission of Ixia.

RESTRICTED RIGHTS LEGENDUse, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph 14(g)(iii) at FAR 52.227 and subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.

The following are trademarks of Ixia:IXIA 100, IXIA 400, IXIA 1600, Optixia, and the Ixia logo.

All other companies and product names and logos are trademarks or registered trademarks of their respective holders.

Part No. 909-0003 Rev BFebruary 5, 2002

Contacting Ixia

Corporate Headquarters

26601 W. Agoura Rd.Calabasas, CA 91302USA

Telephone 1 (877) FOR IXIA (877-367-4942) + 1 (818) 871 1800 (International)

Fax (818) 871-1805

Website www.ixiacom.com

General [email protected]

Investor Relations

[email protected]

Sales [email protected]

Customer Support

[email protected]

Training [email protected]

Table of Contents

Chapter 1 Introduction

The Ixia System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

ScriptGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Layout of This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Advice to Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Chapter 2 Quick Start

Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Test Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

IxSampleTcl Test Program. . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

Chapter 3 Theory of Operation

Ixia Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Chassis Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Ixia Tcl Development Guide iii

Table of Contents

Load Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3Port Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4

Port Transmit Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Streams and Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

Packet Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Packet Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Advanced Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6Frame Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7PPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Transmit Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Port Data Capture Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Continuous vs. Trigger Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Port Capture Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Forced Collision Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10Packet Group Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11Latency Measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11Sequence Checking Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Data Integrity Checking Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

Port Statistics Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14Round Trip TCP Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14

Protocol Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

Internal Versus External BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20IBGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21BGP Router Test Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

RIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23IS-IS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27

PATH Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29Explicit_Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29

RESV Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Other Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31Ixia Test Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31

PPP Protocol Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-32LCP – Link Control Protocol Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33

Maximum Receive Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36Asynchronous Control Character Map . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37

iv Ixia Tcl Development Guide

Table of Contents

Magic Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-37NCP – Network Control Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-38

IPCP – Internet Protocol Control Protocol Options. . . . . . . . . . . . . . . . . .3-38IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-38

OSINLCP - OSI Network Layer Control Protocol . . . . . . . . . . . . . . . . . . .3-39MPLSCP - MPLS Network Control Protocol . . . . . . . . . . . . . . . . . . . . . . .3-39

Retry Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-39Chassis Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40Worldwide Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40

Independent Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-42Ixia 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-42IxClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-43

Bit Error Rate Testing (BERT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44Available / Unavailable Seconds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-46

Ixia Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48

Tcl Software Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49Operation on the Ixia Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50Operation on a Windows Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51Operation on a Unix Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52Multiple Client Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53

Chapter 4 Programming

API Structure and Conventions . . . . . . . . . . . . . . . . . . . . . . . 4-1Standard Sub-Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Sequence of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

How to write efficient scripts . . . . . . . . . . . . . . . . . . . . . . . . 4-10

Multi-Client Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

Mpexpr versus Expr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11

Ixia Tcl Development Guide v

Table of Contents

Chapter 5 IxTclHal API Description

Chassis, Cards and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2chassisChain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3timeServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

mii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7mii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8miiae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8mmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9mmdRegister. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9

USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Packet over Sonet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

sonet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10sonetError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11ppp and pppStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12hdlc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14frameRelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14bert and bertErrorGeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15

portGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15

Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Streams and Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17

stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17Frame Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21

Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21udf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21tcpRoundTripFlows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22packetGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23dataIntegrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Sequence Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24forcedCollisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25

Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26isl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26mpls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27

vi Ixia Tcl Development Guide

Table of Contents

mplsLabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-27IPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28

ipx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-29

arp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-29IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-30

ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-30tcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-31udp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-32igmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-33icmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-33rip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-34ripRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-34dhcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-35

Data Capture and Statistics. . . . . . . . . . . . . . . . . . . . . . . . . 5-36filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36filterPallette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37capture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38captureBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39stat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41statGroup and statList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42qos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43packetGroupStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43

Protocol Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45protocolServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45

ipAddressTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45ipAddressTableItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-47

ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48arpServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-48arpAddressTableEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-49

IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50igmpServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-50igmpAddressTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-51igmpAddressTableItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-52

BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53bgp4Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-53bgp4InternalTable / bgp4ExternalTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-54bgp4InternalNeighborItem / bgp4ExternalNeighborItem. . . . . . . . . . . . . . . . .5-54bgp4RouteItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55

Ixia Tcl Development Guide vii

Table of Contents

bpg4AsPathItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57bgp4StatsQuery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57

OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-58ospfServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-58ospfRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-59ospfRouteRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-61ospfInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62ospfUserLSAGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-64ospfUserLSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-64ospfRouterLSAInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-65

IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-66isisServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66isisRouter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67isisRouteRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69isisInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69

RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-71rsvpServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71rsvpNeighborPair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72rsvpDestinationRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-74rsvpSenderRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-77rsvpEroItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-78rsvpRroItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79

RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-80ripServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-80ripInterfaceRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-81ripRouteRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-83

Chapter 6 High-Level and Utility API Description

Initialization and Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3Mapping and Port Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3

map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5ixCreatePortListWildCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5ixCreateSortedPortList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

Including Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6ixSource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

Chassis and TclServer Connection . . . . . . . . . . . . . . . . . . . . . . . . . .6-6ixInitialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7ixConnectToTclServer / ixDisconnectTclServer . . . . . . . . . . . . . . . . . . . . . . . 6-7ixProxyConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7ixConnectToChassis / ixDisconnectFromChassis . . . . . . . . . . . . . . . . . . . . . . 6-8ixGetChassisID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

viii Ixia Tcl Development Guide

Table of Contents

user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8General Purpose Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9

ixWriteConfigToHardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9ixWritePortsToHardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9

Port Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10ixLogin / ixLogout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10ixCheckOwnership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10ixPortTakeOwnership / ixTakeOwnership / ixPortClearOwnership /

ixClearOwnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

Data Transmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12

ixCheckLinkState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12ixCheckPPPState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13ixSetPortPacketFlowMode / ixSetPacketFlowMode . . . . . . . . . . . . . . . . . . . .6-13ixSetPortPacketStreamMode / ixSetPacketStreamMode . . . . . . . . . . . . . . . .6-13ixSetPortTcpRoundTripFlowMode / ixSetTcpRoundTripFlowMode . . . . . . . .6-14disableUdfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14

Start Transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14ixStartPortTransmit / ixStartTransmit / ixStopPortTransmit / ixStopTransmit .6-14ixStartStaggeredTransmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-15ixCheckPortTransmitDone / ixCheckTransmitDone . . . . . . . . . . . . . . . . . . . .6-15ixStartPortCollisions / ixStartCollisions / ixStopPortCollisions / ixStopCollisions .

6-15Calculation Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16

calculateFrameRate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16calculateGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16validateFramesize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16validatePreamblesize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16host2addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17byte2IpAddr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17dectohex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17hextodec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-17

Data Capture and Statistics. . . . . . . . . . . . . . . . . . . . . . . . . 6-18Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18

ixSetPortCaptureMode / ixSetCaptureMode. . . . . . . . . . . . . . . . . . . . . . . . . .6-18ixSetPortPacketGroupMode / ixSetPacketGroupMode. . . . . . . . . . . . . . . . . .6-18ixClearTimeStamp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19ixClearPortStats / ixClearStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-19ixResetSequenceIndex / ixResetPortSequenceIndex. . . . . . . . . . . . . . . . . . .6-19

Ixia Tcl Development Guide ix

Table of Contents

Capture Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20ixStartPortCapture / ixStartCapture / ixStopPortCapture / ixStopCapture. . . 6-20ixStartPortPacketGroups / ixStartPacketGroups / ixStopPortPacketGroups / ixS-

topPacketGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-20

ixCollectStats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20

Protocol Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Check for Installed Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-22

ixUtils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22isArpInstalled / isBgpInstalled / isIgmpInstalled / isIsisInstalled / isOspfInstalled /

isRipInstalled / isRsvpInstalled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-23

ixEnableArpResponse / ixEnablePortArpResponse . . . . . . . . . . . . . . . . . . . 6-23ixDisableArpResponse / ixDisablePortArpResponse . . . . . . . . . . . . . . . . . . 6-23ixClearPortArpTable / ixClearArpTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23ixTransmitPortArpRequest / ixTransmitArpRequest . . . . . . . . . . . . . . . . . . . 6-24

IGMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-24ixTransmitIgmpJoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24ixTransmitIgmpLeave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24

BGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25ixStartBGP4 / ixStopBGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25ixStartOSPF / ixStopOSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25ixStartISIS / ixStopISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25ixStartRIP / ixStopRIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25ixStartRSVP / ixStopRSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

Console Output and Logging . . . . . . . . . . . . . . . . . . . . . . . 6-27Console Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-27

ixPuts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-27

logOn / logOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27logMsg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28

x Ixia Tcl Development Guide

Table of Contents

Appendix A IxTclHAL Commands

arp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-2

arpAddressTableEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-7

arpServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-8

bert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-12

bertErrorGeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-16

bgp4AsPathItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-19

bgp4ExternalNeighborItem . . . . . . . . . . . . . . . . . . . . . . . . .A-21

bgp4ExternalTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-23

bgp4InternalNeighborItem. . . . . . . . . . . . . . . . . . . . . . . . . .A-25

bgp4InternalTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-27

bgp4RouteItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-29

bgp4Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-33

bgp4StatsQuery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-37

capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-45

captureBuffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-49

card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-53

chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-57

Ixia Tcl Development Guide xi

Table of Contents

chassisChain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-62

collisionBackoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-64

dataIntegrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-65

dhcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-69

filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-76

filterPallette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-83

forcedCollisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-87

frameRelay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-90

hdlc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-93

icmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-98

igmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-102

igmpAddressTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-105

igmpAddressTableItem . . . . . . . . . . . . . . . . . . . . . . . . . . A-107

igmpServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-109

ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-112

ipAddressTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-118

ipAddressTableItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-120

ipx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-122

isisInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-128

xii Ixia Tcl Development Guide

Table of Contents

isisRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-130

isisRouteRange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-133

isisServer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-134

isl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-139

mii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-142

miiae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-146

mmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-149

mmdRegister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-150

mpls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-151

mplsLabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-154

ospfInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-156

ospfRouter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-159

ospfRouteRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-163

ospfRouterLsaInterface . . . . . . . . . . . . . . . . . . . . . . . . . . .A-164

ospfServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-166

ospfUserLsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-171

ospfUserLsaGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-176

packetGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-178

packetGroupStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-183

Ixia Tcl Development Guide xiii

Table of Contents

port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-185

portGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-201

ppp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-205

pppStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-210

protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-213

protocolServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-216

qos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-219

rip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-222

ripRoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-225

ripInterfaceRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-227

ripRouteRange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-230

ripServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-231

rsvpDestinationRange . . . . . . . . . . . . . . . . . . . . . . . . . . . A-235

rsvpEroItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-239

rsvpNeighborPair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-241

rsvpRroItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-244

rsvpSenderRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-246

rsvpServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-248

session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-252

xiv Ixia Tcl Development Guide

Table of Contents

sonet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-254

sonetError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-258

stat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-262

statGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-279

statList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-281

stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-282

tcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-291

tcpRoundTripFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-294

timeServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-299

udf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-303

udp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-307

usb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-310

version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-312

vlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-314

Appendix B Utility Commands

byte2IpAddr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-2

calculateFrameRate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-3

calculateGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-4

Ixia Tcl Development Guide xv

Table of Contents

dectohex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5

disableUdfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6

fastpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

hextodec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8

host2addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9

learn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10

logMsg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-12

logOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13

logOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14

logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15

map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16

mpexpr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18

user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19

validateFramesize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20

validatePreamblesize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21

Appendix C High-Level API

ixCheckLinkState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2

ixCheckOwnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4

xvi Ixia Tcl Development Guide

Table of Contents

ixCheckPPPState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-6

ixCheckPortTransmitDone . . . . . . . . . . . . . . . . . . . . . . . . . .C-7

ixCheckTransmitDone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-9

ixClearArpTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-11

ixClearOwnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-12

ixClearPortArpTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-13

ixClearPortStats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-14

ixClearStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-15

ixClearTimeStamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-17

ixCollectStats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-19

ixConnectToChassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-21

ixConnectToTclServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-23

ixCreatePortListWildCard . . . . . . . . . . . . . . . . . . . . . . . . . .C-24

ixCreateSortedPortList . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-25

ixDisableArpResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-26

ixDisablePortArpResponse . . . . . . . . . . . . . . . . . . . . . . . . .C-28

ixDisconnectFromChassis. . . . . . . . . . . . . . . . . . . . . . . . . .C-29

ixDisconnectTclServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-30

ixEnableArpResponse. . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-31

Ixia Tcl Development Guide xvii

Table of Contents

ixEnablePortArpResponse. . . . . . . . . . . . . . . . . . . . . . . . . C-33

ixGetChassisID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-35

ixInitialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-36

ixIsArpInstalled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-38

ixIsBgpInstalled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-39

ixIsIgmpInstalled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-40

ixIsIsisInstalled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-41

ixIsIsisInstalled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-42

ixIsRipInstalled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-43

ixIsRsvpInstalled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-44

ixGetLineUtilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-45

ixLogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-46

ixLogout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-47

ixPortClearOwnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-48

ixPortTakeOwnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-49

ixProxyConnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-50

ixPuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-52

ixResetPortSequenceIndex . . . . . . . . . . . . . . . . . . . . . . . . C-53

ixResetSequenceIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . C-54

xviii Ixia Tcl Development Guide

Table of Contents

ixSetCaptureMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-56

ixSetPacketFlowMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-58

ixSetPacketGroupMode . . . . . . . . . . . . . . . . . . . . . . . . . . .C-60

ixSetPacketStreamMode. . . . . . . . . . . . . . . . . . . . . . . . . . .C-62

ixSetPortCaptureMode . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-64

ixSetPortPacketFlowMode . . . . . . . . . . . . . . . . . . . . . . . . .C-65

ixSetPortPacketGroupMode . . . . . . . . . . . . . . . . . . . . . . . .C-66

ixSetPortPacketStreamMode . . . . . . . . . . . . . . . . . . . . . . .C-67

ixSetPortTcpRoundTripFlowMode. . . . . . . . . . . . . . . . . . . .C-68

ixSetTcpRoundTripFlowMode . . . . . . . . . . . . . . . . . . . . . . .C-69

ixSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-71

ixStartBGP4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-72

ixStartCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-74

ixStartCollisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-76

ixStartIsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-78

ixStartOspf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-80

ixStartPacketGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-82

ixStartPortCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-84

ixStartPortCollisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-85

Ixia Tcl Development Guide xix

Table of Contents

ixStartPortPacketGroups . . . . . . . . . . . . . . . . . . . . . . . . . . C-87

ixStartPortTransmit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-89

ixStartRip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-90

ixStartRsvp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-92

ixStartStaggeredTransmit. . . . . . . . . . . . . . . . . . . . . . . . . . C-94

ixStartTransmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-96

ixStopBGP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-98

ixStopCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-100

ixStopCollisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-102

ixStopIsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-104

ixStopOspf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-106

ixStopPacketGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-108

ixStopPortCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-110

ixStopPortCollisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-112

ixStopPortPacketGroups . . . . . . . . . . . . . . . . . . . . . . . . . C-114

ixStopPortTransmit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-116

ixStopRip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-117

ixStopRsvp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-119

ixStopTransmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-121

xx Ixia Tcl Development Guide

Table of Contents

ixTakeOwnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-123

ixTransmitArpRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-124

ixTransmitIgmpJoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-126

ixTransmitIgmpLeave . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-128

ixTransmitPortArpRequest . . . . . . . . . . . . . . . . . . . . . . . .C-130

ixUtils. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-131

ixWriteConfigToHardware . . . . . . . . . . . . . . . . . . . . . . . . .C-133

ixWritePortsToHardware . . . . . . . . . . . . . . . . . . . . . . . . . .C-135

Appendix D Miscellaneous Unsupported Commands

send_arp_frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-2

send_fastpath_frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-3

send_learn_frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-4

send_ripx_frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-5

Appendix E ScriptGen Usage

ScriptGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .E-1Invoking ScriptGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1

Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1Unix Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2

Appendix F TclServer Usage

TclServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-1

Ixia Tcl Development Guide xxi

Table of Contents

Installation and Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . F-2

Tcl Server Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-3Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-4Advance Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .F-5

Appendix G Available Statistics

Table Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-2IxExplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-2

Statistics Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-2Extra Statistics Checkboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-2Receive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-3Key To Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-3

TCL Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-4Statistics Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-4Extra Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-4Receive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-5

C++ Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-5Statistics Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-5Extra Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-5Receive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-6

Description of Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-6Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-19

xxii Ixia Tcl Development Guide

List of Figures

Figure 1-1. System Overview Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2Figure 2-2. Expected Output from IxSampleTcl.tcl Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2Figure 2-3. Sample Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3Figure 3-4. Ixia Chassis Chain and Control Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2Figure 3-5. Ixia 1600 Interior View (Top View) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3Figure 3-6. Inter-Stream Gap (ISG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6Figure 3-7. Inter-Burst Gap (IBG)/Burst Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6Figure 3-8. Inter-Packet Gap (IPG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7Figure 3-9. Forced Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11Figure 3-10. Packet Format for Packet Groups/Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11Figure 3-11. Multiple Latency Time Measurements - Example . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12Figure 3-12. Packet Format for Sequence Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13Figure 3-13. Packet Format for Data Integrity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14Figure 3-14. RoundTrip TCP Flows Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15Figure 3-15. Sample OSPF Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19Figure 3-16. EBGP versus IBGP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20Figure 3-17. BGP Interconnection Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21Figure 3-18. Generation of Network Addresses in BGP UPDATE Messages . . . . . . . . . . . . . . . .3-22Figure 3-19. IS-IS Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26Figure 3-20. RSVP-TE Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27Figure 3-21. Worldwide Deployment of Synchronized Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . .3-40Figure 3-22. Independent Chassis Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-42Figure 3-23. Chassis Timing Using an Ixia 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-43Figure 3-24. IxClock Chassis Timing Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-44Figure 3-25. BERT Inserted Error Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-45Figure 3-26. BERT- Unavailable/Available Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-47Figure 3-27. Software Modules used on an Ixia Chassis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-50Figure 3-28. Software Modules used on a Windows Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-51

Ixia Tcl Development Guide xxiii

List of Figures

Figure 3-29. Software Modules used on a Unix Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52Figure 3-30. Multi-Client Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53Figure 4-31. Standard Method Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3Figure 5-32. IGMP Command Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50Figure 5-33. BGP4 Command Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53Figure 5-34. OSPF Command Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-58Figure 5-35. ISIS Command Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66Figure 5-36. RSVP Command Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71Figure 5-37. RIP Command Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-80Figure 6-1. Traffic Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Figure E-1. Wish Console Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .E-1Figure E-2. ScriptGen Usage Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .E-2Figure F-1. Tcl Server on an Ixia Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-1Figure F-2. Tcl Server on an Independent Windows Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-2Figure F-3. Initial Tcl Server Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-3Figure F-4. Tcl Server with Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-3Figure F-5. IxTclServer Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-4Figure F-6. Serial Port Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-6Figure G-7. Statistics Mode Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-2Figure G-8. Receive Mode Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-3

xxiv Ixia Tcl Development Guide

List of Tables

TABLE 4-1. Standard Options4-1TABLE 4-2. Traffic Map Array4-5TABLE 5-20. session Options5-2TABLE 5-21. session Sub-Commands5-2TABLE 5-22. chassisChain Options5-3TABLE 5-23. chassisChain Sub-Commands5-3TABLE 5-24. timeServer Command Options5-3TABLE 5-25. chassis Options5-4TABLE 5-26. chassis Sub-Commands5-4TABLE 5-27. card Options5-4TABLE 5-28. port Options5-5TABLE 5-29. port Sub-Commands5-7TABLE 5-30. mii Options5-8TABLE 5-31. mii Sub-Commands5-8TABLE 5-32. miiae Options5-8TABLE 5-33. miiae Sub-Commands5-8TABLE 5-34. mmd Options5-9TABLE 5-35. mmd Sub-Commands5-9TABLE 5-36. mmdRegister Options5-9TABLE 5-37. usb Options5-10TABLE 5-38. usb Sub-Commands5-10TABLE 5-39. sonet Options5-11TABLE 5-40. sonetError Options5-12TABLE 5-41. sonetError Sub-Commands5-12TABLE 5-42. ppp/pppStatus Options5-12TABLE 5-43. hdlc Options5-14TABLE 5-44. hdlc Sub-Commands5-14TABLE 5-45. frameRelay Options5-14TABLE 5-46. bert Options5-15TABLE 5-47. bertErrorGeneration Options5-15

Ixia Tcl Development Guide xxv

List of Figures

TABLE 5-48. bertErrorGeneration Sub-Commands5-15TABLE 5-49. portGroup Options5-16TABLE 5-50. portGroup Sub-Commands5-16TABLE 5-51. stream Options5-18TABLE 5-52. stream Sub-Commands5-21TABLE 5-53. udf Options5-21TABLE 5-54. tcpRoundTripFlows options5-22TABLE 5-55. packetGroup Options5-23TABLE 5-56. packetGroup Sub-Commands5-23TABLE 5-57. dataIntegrity Options5-24TABLE 5-58. dataIntegrity Sub-Commands5-24TABLE 5-59. forcedCollisions Members5-25TABLE 5-60. protocol Options5-25TABLE 5-61. isl Options5-26TABLE 5-62. vlan Options5-26TABLE 5-63. mpls Options5-27TABLE 5-64. mpls Options5-27TABLE 5-65. ipx options5-28TABLE 5-66. arp options5-29TABLE 5-67. ip Options5-30TABLE 5-68. tcp options5-31TABLE 5-69. udp Options5-32TABLE 5-70. igmp Options5-33TABLE 5-71. icmp Options5-33TABLE 5-72. rip Options5-34TABLE 5-73. ripRoute Options5-34TABLE 5-74. dhcp Options5-35TABLE 5-75. dhcp Sub-Commands5-35TABLE 5-76. filter Options5-37TABLE 5-77. filterPallete Options - DA/SA5-38TABLE 5-78. filterPallette Options - Pattern 1/25-38TABLE 5-79. capture Options5-38TABLE 5-80. captureBuffer Options5-39TABLE 5-81. captureBuffer Sub-Commands5-40TABLE 5-82. statistics Options5-41TABLE 5-83. statistics Sub-Commands5-41TABLE 5-84. statGroup Options5-42TABLE 5-85. statGroup Sub-Commands5-42TABLE 5-86. statList Options5-42TABLE 5-87. statList Sub-Commands5-42TABLE 5-88. qos Options5-43TABLE 5-89. qos Sub-Commands5-43TABLE 5-90. packetGroupStats options5-43TABLE 5-91. packetGroupStats Sub-Commands5-44TABLE 5-92. protocolServer Options5-45

xxvi Ixia Tcl Development Guide

List of Tables

TABLE 5-93. Typical Address Table Operations5-46TABLE 5-94. ipAddressTable Options5-46TABLE 5-96. addressTableItem Options5-47TABLE 5-97. addressTableItem Sub-Commands5-47TABLE 5-95. ipAddressTable Sub-Commands5-47TABLE 5-98. Typical Address Table Operations5-48TABLE 5-99. arpServer Options5-48TABLE 5-101. arpAddressTableEntry Options5-49TABLE 5-100. arpServer Sub-Commands5-49TABLE 5-102. igmpServer Options5-50TABLE 5-103. Typical Address Table Operations5-51TABLE 5-104. igmpAddressTable Sub-Commands5-52TABLE 5-105. igmpAddressTableItem Options5-52TABLE 5-106. bgp4InternalTable / bgp4ExternalTable Options5-54TABLE 5-107. bgp4InternalTable / bgp4ExternalTable Sub-Commands5-54TABLE 5-108. bgp4InternalNeighborItem / bgp4ExternalNeighborItem Options5-55TABLE 5-109. bgp4InternalNeighborItem / bgp4ExternalNeighborItem Sub-Commands5-55TABLE 5-110. bgp4RouteItem Options5-56TABLE 5-112. bgp4AsPathItem Options5-57TABLE 5-113. bgp4StatsQuery Options5-57TABLE 5-114. bgp4StatsQuery Sub-Commands5-57TABLE 5-111. bgp4RouteItem Sub-Commands5-57TABLE 5-115. ospfServer Sub-Commands5-59TABLE 5-116. ospfRouter Options5-60TABLE 5-117. ospfRouter Sub-Commands5-60TABLE 5-118. ospfRouteRange Options5-61TABLE 5-119. ospfInterface Options5-62TABLE 5-120. ospfInterface Sub-Commands5-63TABLE 5-121. ospfUserLSAGroup Options5-64TABLE 5-122. ospfUserLSAGroup Sub-Commands5-64TABLE 5-123. ospfUserLSA Sub-Commands5-65TABLE 5-124. isisServer Sub-Commands5-66TABLE 5-125. isisRouter Options5-67TABLE 5-126. isisRouter Sub-Commands5-68TABLE 5-127. isisRouteRange Options5-69TABLE 5-128. isisInterface Options5-69TABLE 5-129. rsvpServer Sub-Commands5-72TABLE 5-130. rsvpNeighborPair Options5-73TABLE 5-131. rsvpRouter Sub-Commands5-73TABLE 5-132. rsvpDestinationRange Options5-75TABLE 5-133. rsvpDestinationRange Sub-Commands5-76TABLE 5-134. rsvpSenderRange Options5-77TABLE 5-135. rsvpEroItem Options5-79TABLE 5-136. rsvpRroItem Options5-79TABLE 5-137. ripServer Sub-Commands5-80

Ixia Tcl Development Guide xxvii

List of Figures

TABLE 5-138. ripInterfaceRouter Options5-81TABLE 5-139. ripInterfaceRouter Sub-Commands5-82TABLE 5-140. ripRouteRange Options5-83TABLE 6-1. map Options6-5TABLE 6-2. map Sub-Commands6-5TABLE 6-3. user Options6-8TABLE 6-4. logger Options6-28TABLE 6-5. logger Sub-Commands6-28TABLE E-1. ScriptGen Usage Dialog FieldsE-2TABLE F-1. Tcl Server MenusF-4Table F-1. IxTclServer OptionsF-5Table F-2. Tcl Server Menu OptionsF-5

xxviii Ixia Tcl Development Guide

1The Ixia SystemThe Ixia system is the most comprehensive tool available for testing multi-layer 10/100 Mbps Ethernet, Gigabit Ethernet and Packet over Sonet switches, routers, and networks. The Optixia offers the highest port density available with support for up to 480 ports in a chassis. Depending on technology, up to four ports are packaged on a card, also referred to as a load module. Any combination of cards may be included in a single chassis. The IXIA 400 is a powerful desktop system that holds four load modules of any type. The highly scalable architecture sup-ports daisy-chaining of up to 256 chassis that may be synchronized to within 10 nanoseconds. Thus, even the most complex systems can be tested thoroughly and cost-effectively.

The Ixia product family includes the chassis, load modules, the IxExplorer soft-ware program, and optional Tcl scripts and related software as well as Tcl and C++ development environments. A chassis can be configured with any mix of load modules, and multiple chassis can be daisy-chained and synchronized to support very large and complex test environments. The IxExplorer software pro-vides complete configuration, control, and monitoring of all Ixia resources in the test network, and the Tcl scripts allow the user to rapidly conduct the most popu-lar industry benchmark tests.

The user can configure and control the unit directly via back-panel connections to a keyboard, mouse, monitor, and printer. Also, the unit can be connected to an Ethernet network and an administrator can remotely monitor and control it using the IxExplorer software program. Multiple users can access the unit simulta-neously, splitting the ports within a chassis and controlling the activity and con-figuration of all ports and functions.

Front panel displays give immediate indication of link state, transmission or reception of packets, and error conditions.

This guide provides a description of the Ixia's Tcl Command Library for writing customized Tcl application programs to control the Ixia hardware platform.

Chapter 1: Introduction

Ixia Tcl Development Guide 1-1

IntroductionThe Ixia System1

The Ixia Tcl Command library provides full access to the Ixia hardware platform. Configurations can be sent to the hardware and various programs can be created and executed on the system. Tcl scripting allows automation of testing proce-dures when tens to thousands of ports are involved. Ixia’s Tcl Command Library is built using a combination of commands that are written in Tcl and commands that are implemented in C/C++. The figure below shows the location of the C++ API Client (IxTclHAL) in the overall picture of the Ixia hardware platform.

Figure 1-1. System Overview Diagram

The IxServer module resides on the computer connected to the test hardware and is responsible for control and operation of the hardware. A single IxServer mod-ule exists per chassis.

The IxHAL (Hardware Abstraction Layer) is a C++ based application that pro-vides a higher level abstraction of the Ixia hardware. Working with IxServer, it operates the hardware chassis, cards and ports. When the test software (IxEx-plorer, ScriptMate, Tcl based applications and C++ based applications) reside on a different computer than the test hardware, an additional IxHAL copy resides on the remote machine. These two copies act in concert to provide a single interface to upper layers of software.

IxHAL serves as a buffer for configuration information, saving and buffering this data until it receives a command to transfer the data to or from the hardware via

IxExplorer

IxHAL IxHAL

IxTclHAL

Tcl Client

IxHAL

IxServer

HARDWARE

1-2 Ixia Tcl Development Guide

IntroductionThe Ixia System

IxServer. The IxExplorer software, for example, uses its copy of IxHAL to hold configuration data until it is transferred to the hardware.

In the case of Tcl applications, the Tcl Command Library is a set of Tcl com-mands that are used to configure the traffic generation, capture and statistics parameters on the Ixia hardware platform. Tcl applications use these commands to configure test parameters and then use a ‘set’ option to transfer the information into IxHAL. A ‘write’ option causes IxHAL to send the information to the hard-ware. To retrieve status, captured data and statistics the application uses a ‘get’ option which retrieves the information from IxHAL into IxTclHAL. A ‘cget’ option retrieves these values for use in Tcl applications.

Discussions of Tcl commands can be found in:• IxTclHal API Description – a discussion of the Tcl commands in IxTclHAL.• Appendix A - IxTclHAL Commands – a complete description of the Tcl Com-

mand Library. • Appendix B - Utility Commands – a number of additional provided utility

commands.a number of additional Tcl commands that are used in most tests. • Appendix C - High-Level API – a number of additional Tcl commands that are

used in most tests. • Appendix D - Miscellaneous Unsupported Commands – additional commands

provided without support.

Custom applications or test scripts can be written using Ixia's Tcl Command Library. For Windows users, as in standard Tcl/Tk packages, Ixia provides a Dynamic Link Library (DLL) file for Windows 95/NT that may be loaded into a standard Tcl shell or Wish Console. The DLL gives access to the IxTclHal Com-mand library.

For Unix users, the IxTclHal package connects to an instance of a TclServer on a Ixia chassis, where the DLL is used.

After installing the Tcl Client on the workstation, the Tcl package can be loaded by launching the Tcl Shell (double-clicking the Wish Console icon on the Desk-top) and typing in the following command:

%package require IxTclHal

Now all the Ixia Tcl commands will be available. If a new script is to be written, this should be the first line of the script file. The package command can also be used inside a previously written script, which could be loading other Tcl exten-sions such as Expect, Tcl-DP.


IntroductionScriptGen1

ScriptGenScriptGen is an auxiliary Tcl tool that is installed as part of the Tcl Client pack-age. It’s purpose is to create a Tcl program which reflects the configuration of a particular port. ScriptGen is run from a Wish Console and the resulting program is written to disk and shown in the console window. The configuration of the port may have been established through the use of any of the Ixia tools: IxExplorer, ScriptMate, TCL API or C++ API. The operation of ScriptGen is described in Chapter E - ScriptGen.


IntroductionLayout of This Manual

Layout of This ManualThis Guide has a number of chapters and appendices in order to convey usage and reference information.

The chapters of the manual are:

Chapter 1 - Introduction. This chapter.

Chapter 2 - Quick Start. An overview of a complete, useful Tcl example pro-gram. Using this, the basic flow of programming and operation can be viewed.

Chapter 3 - Theory of Operation. Explains the conceptual model behind the Ixia hardware, so that the API’s functions and features can be completely understood.

Chapter 4 - Programming. Explains the basic structure and operation of all of the Tcl Commands.

Chapter 5 - IxTclHal API Description. Organizes the APIs into related discussion groups and describes how to use them at a high level.

Appendix A - IxTclHAL Commands. An alphabetical set of reference sheets for all of the Tcl Commands.

Appendix B - Utility Commands. An alphabetical set of reference sheets for additional test related commands.

Appendix C - High-Level API. Commands which perform a combination of functions against a number of ports.

Appendix D - Miscellaneous Unsupported Commands. An alphabetical set of reference sheets for supplied utility commands.

Appendix E - ScriptGen Usage. A description of the ScriptGen utility usage.

Appendix G - Available Statistics. A description of available statistics.


IntroductionAdvice to Readers1

Advice to ReadersEveryone should read and understand the Quick Start chapter. Most C++ pro-grams will follow a very similar structure.

People unfamiliar with the Ixia system should read the Theory of Operation chapter to understand how the hardware functions.

The Programming chapter is an essential element in understanding how the APIs are to be used.

The API description chapter should be read, in part, as the elements are needed. For example, you need not read the Packet over Sonet (sonet, etc.) sections until you need to use PoS cards.

The appendices should be used for reference.


2Development EnvironmentThis chapter provides a quick means of getting started with the Tcl API. An example test is presented and explained.

The IxSampleTcl.tcl file may be run only in the following environment:

• On the Ixia chassis.

• On a computer running Windows 95/98/NT/2000 or on Sun Solaris or Red Hat Linux systems. You must install the Ixia Tcl client on the platform

The test script is configured to expect a 2-port or 4-port card in chassis slot 4, for a user george connecting to chassis work. Change these in the source file as nec-essary for your scenario.

The example is located in the <installation location>\TclScripts\SampleStd directory. This is usually C:\Program Files\Ixia\TclScripts\SampleStd. The steps necessary to build and execute IxSampleC.cpp are:

1. Start the Wish Console from the Ixia program group in the Start menu.

2. Use the File->Source menu option to open the IxSampleTcl.tcl file or type

source “c:/Program Files/Ixia/TclScripts/SampleStd/IxSampleTcl.tcl”

3. The expected output for two 10/100 ports is shown in Figure 2-2 on page 2-2.

(1)Ixia Tcl Sample Script(2)(3)User logged in as: george(4)Connecting to Chassis 1: 192.168.3.61 ...(5)Took ownership of following ports:(6){1 2 1} {1 2 2}(7)(8)IxTclHAL Version :3.50(9)Product version :3.50(10)Installed version :Ixia Software v12(11)(12)Setting ports to factory defaults...

Chapter 2: Quick Start


Quick StartDevelopment Environment2

(13)Checking link states on ports ...(14)Links on all ports are up.(15)Configuring 1 2 1 --> 1 2 2(16)Resetting Statistics ...(17)Start capture...(18)Start transmit...(19)Transmittion is complete.(20)Stop capture...(21)(22)Number of frames sent :200(23)Tx line speed :100(24)Rx line speed :100(25)Number of frames received :200(26)Number of packets captured :200(27)(28)Sample test complete.(29)(30)0

Figure 2-2. Expected Output from IxSampleTcl.tcl Execution


Quick StartTest Environment

Test EnvironmentThe test environment in which the IxExampleTcl.tcl test executes is illustrated in Figure 2-3 on page 2-3.

Figure 2-3. Sample Test Setup

ProgrammingStation

Card 1 Card 2 Card 3 Card 4 Card 5 Card 6 Card 7 Card 8 Card 9 Card 10 Card 11 Card 12 Card 13 Card 14 Card 15 Card 16

Port 1

Port 2

Ixia Chassis


Quick StartIxSampleTcl Test Program2

IxSampleTcl Test ProgramThe IxSampleTcl.tcl file is included just below, along with comments which explain the test.(1) # The following is an example of how streams, ports and filters are (2) # configured, data capture started, transmission started and statistics (3) # collected.(4) # The chassis is connected to first, streams are created, filters are set,(5) # then capture is started on Rx port and transmisssion is started on Tx port.(6) # After the transmission is complete, some statistics are collected and (7) # displayed to standard out. (8) # Note: This test requires two ports which should be connected via a(9) # loopback cable.(10)(11)# This package is required to have access to the Ixia Tcl commands(12) package req IxTclHal(13)(14) set userName george(15) set hostname work(16) set chasId 1 ;# This test presumes chassis 1(17) set card 4 ;# Card number four(18) set txport 1 ;# Port 1 transmits and(19) set rxport 2 ;# Port 2 receives(20)(21) # The high level API commands can either use a list of ports or(22) # work with a global array as defined below (23) set txPortList {{1 4 1}} (24) set rxPortList {1,4,2} (25) set portList {{1 4 1} {1 4 2}}(26)(27) ixPuts “\n\tIxia Tcl Sample Script”(28)(29) # Log in user(30) ixLogin $userName ;# User login allows for multi-user programming(31) ixPuts “\nUser logged in as: $userName”(32)(33) if [ixInitialize $hostname] {(34) return 1(35) }(36)(37) # Take ownership of the ports(38) if [ixTakeOwnership $portList]{(39) return 1(40) }(41)(42)(43) ##################################################################(44) # Set up one to one port mapping and remove any existing map(45) map new -type one2one (46) map config -type one2one(47)(48) # --------- TX --------- --------- RX ---------(49) # chassis card port chassis card port(50) map add $chasId $card $txport $chasId $card $rxport(51) ##################################################################(52)(53)(54) # Display version information(55) ixPuts “\nIxTclHAL Version :[version cget -ixTclHALVersion]”(56) ixPuts “Product version :[version cget -productVersion]”


Quick StartIxSampleTcl Test Program

(57) ixPuts “Installed version :[version cget -installVersion]\n”(58) (59)(60) # Set ports to factory defaults(61)(62) ixPuts “Setting ports to factory defaults...”(63) if [port setFactoryDefaults $chasId $card $txport] {(64) errorMsg “Error setting factory defaults on port $txport.”(65) set retCode 1(66) }(67) if [port setFactoryDefaults $chasId $card $rxport] {(68) errorMsg “Error setting factory defaults on port $rxport.”(69) set retCode 1(70) } (71) # Writes port properties in hardware(72) if {[ixWritePortsToHardware one2oneArray]} {(73) ixPuts “Error writing port to hardware” (74) set retVal 1 (75) }(76) (77) # Checks the link state of the ports(78) if {[ixCheckLinkState one2oneArray]} {(79) return -code error(80) }(81)(82) logMsg “Configuring $chasId $card $txport --> $chasId $card $rxport”(83) (84) # Set default values(85) stream setDefault(86) udf setDefault(87) filter setDefault(88) filterPallette setDefault(89)(90) stream config -numFrames 10 ;# Generate 10 frames(91) stream config -framesize 64 ;# each of 64 bytes(92)(93) # get the mac & Ip addresses for the destination/source addresses(94) if [port get $chasId $card $txport] {(95) errorMsg “TxPort $chasId,$card,$txport not configured yet!”(96) set retCode 1(97) }(98) # Stream’s source address is default port Mac Address(99) stream config -sa [port cget -MacAddress](100)(101) # Same for receive port(102) if [port get $chasId $card $rxport] {(103) errorMsg “RxPort $chasId,$card,$rxport not configured yet!”(104) set retCode 1(105) }(106) stream config -da [port cget -MacAddress] (107)(108) # Configure 20 streams on Tx port(109) for {set streamID 1} {$streamID <= 20} {incr streamID} {(110) # IP addresses are based on stream number(111) ip config -sourceIpAddr $streamID.1.1.1(112) ip config -destIpAddr $streamID.1.1.2(113)(114) if [ip set $chasId $card $txport] {(115) logMsg “Error setting IP on $chasId,$card,$txport”(116) set retCode 1(117) }(118)(119) # set each stream to advance to the next



(120) stream config -name “stream $streamID”(121) stream config -dma advance(122) # Except for the last one, which will stop(123) if { $streamID == 20 } {(124) stream config -dma stopStream(125) }(126) (127) # Set user defined field 4 to set a single value of “db010402” in (128) # this example(129) set udfPattern [format “db %02x %02x %02x” $chasId $card $rxport](130)(131) udf config -enable true(132) udf config -offset 42(133) udf config -initval $udfPattern(134) udf config -countertype c32(135) udf config -maskselect {00 00 00 00}(136) udf config -maskval {00 00 00 00}(137) udf config -random false(138) udf config -continuousCount false(139) udf config -repeat 1(140)(141) if [udf set 4] {(142) errorMsg “Error setting UDF 4”(143) set retCode 1(144) }(145) # Set the stream data(146) if [stream set $chasId $card $txport $streamID] {(147) errorMsg “Error setting stream $streamID on $chasId,$card,$txport”(148) set retCode 1(149) } (150) } (151) (152) # Set the filter parameters on the receive port to look for UDF pattern(153) filterPallette config -pattern2 $udfPattern(154) filterPallette config -patternOffset2 [udf cget -offset](155)(156) # Set up user defined statistics to count the pattern(157) filter config -userDefinedStat2Pattern pattern2(158) filter config -userDefinedStat2Enable true(159) filter config -userDefinedStat2Error errGoodFrame (160)(161) # Must enable capture trigger and filter(162) filter config -captureTriggerEnable true(163) filter config -captureFilterEnable true(164)(165) # Set values for filter pallette(166) if [filterPallette set $chasId $card $rxport] {(167) errorMsg “Error setting filter pallette for $chasId,$card,$rxport.”(168) set retCode 1(169) }(170)(171) # set values for filter(172) if [filter set $chasId $card $rxport] {(173) errorMsg “Error setting filters on $chasId,$card,$rxport.”(174) set retCode 1(175) } (176) (177) # Writes all the configuration on ports in hardware(178) if [ixWriteConfigToHardware one2oneArray] {(179) return -code error(180) }(181)


Quick StartIxSampleTcl Test Program

(182) # Zero all statistic counters on ports(183) if [ixClearStats one2oneArray] {(184) return -code error(185) }(186) (187)(188) # Start capture on Rx port(189) ixPuts “Start capture...” (190) if [ixStartCapture rxPortList] {(191) return -code error(192) }(193)(194) # Start transmission on Tx port(195) ixPuts “Start transmit...”(196) if [ixStartTransmit txPortList] {(197) return -code error(198) }(199) after 2000(200) # Checks whether transmission is done on a group of ports(201) if {[ixCheckTransmitDone txPortList] == 0} {(202) return -code error(203) }(204) ixPuts “Transmission is complete.”(205) (206) # Stop capture on ports(207) ixPuts “Stop capture...”(208) if [ixStopCapture rxPortList] {(209) return -code error(210) }(211)(212) # Wait a second(213) after 1000(214)(215) if [stat get statAllStats $chasId $card $txport] {(216) ixPuts “Statistics get statAllStats failed for $chasId $card $rxport”(217) return 1(218) }(219) ixPuts “\nNumber of frames sent :[stat cget -framesSent]”(220) ixPuts “Tx line speed :[stat cget -lineSpeed]”(221) (222) if [stat get statAllStats $chasId $card $rxport] {(223)i ixPuts “Statistics get statAllStats failed for $chasId $card $rxport”(224) return 1(225) }(226) (227) ixPuts “Rx line speed :[stat cget -lineSpeed]”(228) ixPuts “Number of frames received :[stat cget -userDefinedStat2]” (229)(230) if [capture get $chasId $card $rxport] {(231) ixPuts “Error getting capture data on #chasId $card $rxport”(232) return 1(233) }(234) ixPuts “Number of packets captured :[capture cget -nPackets]”(235)(236) ixPuts “\nSample test complete.\n”(237) (238) # Clear the ownership of the ports(239) ixClearOwnership $portList(240)(241) # Log off user(242) ixLogout


3Chapter 3: Theory of Operation

Ixia HardwareIn this chapter, we’ll discuss the unifying concepts behind the Ixia system. Both the software and hardware structures, and their usage, will be discussed.

Chassis Chain At the highest level, the Ixia hardware is structured as a chain of chassis—up to 256 of them, of four different types of chassis. The Optixia chassis is capable of holding up to 480 ports. The Ixia 1600 chassis is capable of holding up to 16 load modules of various media types and speeds. The Ixia 400 chassis is capable of holding up to 4 load modules. The Ixia 100 chassis is capable of holding one load module. Each load module for 100/400/1600 chassis supports up to 8 ports. Up to 48 ports are supported on Optixia load modules—which can result in a very large number of ports for the overall system. Multiple Ixia chassis are chained together through special Sync-out/Sync-in cables that allow for port-to-port synchroniza-tion across locally connected chassis within 10ns.

Figure 3-4 is a representation of an independent Ixia chassis chain and control network. Chassis are chained together through their sync cables. The first chassis in a chain has a Sync-out connection (no Sync-in) , and is called the ‘Master’ chassis. All other chassis in the chain are termed ‘Slaves’.


Theory of OperationIxia Hardware3

Figure 3-4. Ixia Chassis Chain and Control Workstation

Multiple, geographically-separated, independent chassis and chassis chains may be synchronized with a high degree of accuracy by using alternate time sources, an Ixia 100 chassis, and/or an IxClock module. Both the Ixia 100 and IxClock devices include an integral GPS or CDMA receiver which is used for worldwide chassis synchronization. See Chassis Synchronization on page 3-40 for a com-plete discussion of chassis timing.

Ports from the chassis are connected to the Device Under Test (DUT) using cables appropriate for the media. Ports from any chassis may be connected to the similar ports on the DUT. It is even possible to connect multiple independent DUT’s to different ports on different chassis.

Each chassis is driven by an Intel Pentium-based PC running Windows 2000 or 95, and Ixia-supplied software. Each chassis may be directly connected to a mon-itor, keyboard, and mouse to create a stand-alone system, but it is typical to con-nect all chassis via an Ethernet network and run the IxExplorer client software, Tcl client software, or C++ API-based software on one or more external control PC workstations. Tcl client software runs on Windows NT/95/98/2000 based systems as well as several Unix-based systems.

Chassis Each Ixia chassis can operate as a complete stand-alone system, when connected to a local monitor, keyboard, and mouse. The interior of an Ixia 1600 chassis is shown in Figure 3-5.

Device Under Test (DUT)

Ethernet Network

Workstation

Sync

Workstation

Syncout in

Master

Other SlavesSyncout

Control Workstations

Slave


Theory of OperationIxia Hardware

Figure 3-5. Ixia 1600 Interior View (Top View)

The PC embedded in the chassis system is an Intel-compatible computer system which includes:

• A Pentium processor

• Main memory

• Keyboard interface

• Mouse interface

• Internal connection to the Ixia Backplane

• Video interface capable of 1024 x 768 resolution

• 10/100 Mbps Ethernet Network Interface Card (NIC)

The Ixia Backplane is connected to the PC Motherboard, through an Ixia custom ISA interface card, and to the card slots where the Ixia load modules are installed.

Load Modules Although each Ixia load module differs in particular capabilities, all modules share a common set of functions. Ixia load modules are generally categorized by network technology. The network technologies supported, along with names used to reference these technologies and more detailed information on load mod-ule differences, are available in the Ixia Hardware Guide.

The Load Module Name Prefix is used as the prefix to all load modules for that technology; for example, LM 100 in LM 100 TX.

Some load modules are further labelled by the type of connector supported. Thus, a load module’s name can be formed from a combination of its basic technology and the connector type. For example, LM 100 TX is the name of the 10/100 load module with RJ-45 connectors. An example for Packet Over Sonet (POS) is the LMOC48c POS module, where no connector type is specified.

In addition, less expensive versions of several load modules are available. These are called Type-3 or Type-M modules, signified by an ending of ‘-3’ or ‘-M’ in the load module name.

NIC Card PC Motherboard

Load Modules

Ixia Backplane/Bus

Ethernet link

(FRONT)

(BACK)



Port Hardware The ports on the Ixia load modules provide high-speed, sophisticated transmit, capture, and statistics operation. The discussion which follows is broken down into a number of areas:

• Port Transmit Capabilities—facilities for generating data traffic

• Streams and Flows—a set of packets, which may be grouped into bursts

• Bursts—a number of packets

• Packets—individual frames/packets of data

• Frame Data—the construction of data within a frame/packet

• Port Data Capture Capabilities—facilities for capturing data received on a port

• Port Statistics Capabilities—facilities for obtaining statistics on each port

Port Transmit Capabilities

The Ixia module ports format data to be transmitted in a hierarchy of structures:

• Streams and Flows- A set of related packet bursts

• Bursts- A repetition of packets

• Packets- Individual packets/frames

Streams and Flows

The Ixia system uses sophisticated models for the programming of data to be transmitted. There are two general modes of scheduling data packets for trans-mission:

• Sequential - the first configured stream in a set of streams is transmitted completely before the next one is sent, and so on, until all of the configured streams have been transmitted. Two types are available on Ixia modules:

• Packet Streams

• Packet Flows (available on certain modules)

• Interleaved - the individual packets in the streams are multiplexed into a single stream, where the total packet rate is the sum of the packet rates for each of the streams. One type is available:

• Advanced Streams (Advanced Stream Scheduler feature)

Packet Streams

This sequential transmission model is supported by the Ixia load modules, where dedicated hardware can be used to generate up to 255 Packet Streams “on-the-fly”, with each stream consisting of up to 16 million bursts of up to 16 million packets each. Transmission of the entire set of packet streams may be repeated continuously for an indefinite period, or repeated only for a user-specified count. The variability of the data within the packets is necessarily generated algorithmi-cally by the hardware transmit engine.



Packet Flows

A second sequential data transmission model is supported by software for any Ixia port which supports Packet Flows. An individual packet flow can consist of from 1 to 15,872 packets. For packet flows consisting of only one unique packet each, a maximum of 15,872 individual flows can be transmitted. Because the packets in each of the packet flows is created by the software, including UDF fields and checksums, and then stored in memory in advance of data transmis-sion, there can be more unique types of packets than is possible with streams. Continuous transmission cannot be selected for flows, but by using a return loop, the flows can be re-transmitted for a user-defined count.

Packet streams, which can contain larger amounts of data, are based on only one packet configuration per stream. In contrast, many packet flows can be config-ured for a single data transmission, where each flow consists of packets with a configuration unique to that flow.

Advanced Streams

A third type of streams is called Advanced Stream Scheduling, which involves interleaving of all defined streams at the same time. Each stream is assigned a percentage of the maximum rate. The streams are mixed in a pseudo-random manner so that each stream’s long-term percentage of the total transmitted data is as specified by the user. Advanced Stream Scheduling is available for Packet Over SONET modules (except for the OC-12c/OC-3c and most Type-M mod-ules), 10 GE LAN modules, and 10/100 TXS8 modules.

When multiple transmit modes are available, the transmit mode for each port must be set by the user to indicate whether it will use streams, flows, or advanced stream scheduling. The programming of sequential streams or flows is according to the same programming model, with a few exceptions related to continuous bursts of packets. Since the model is identical in both cases, we will refer to both streams and flows as “streams” while discussing programming.

There are three basic types of sequential streams:

• Continuous Packet—a continuous stream of packets. The packets are not nec-essarily identical; their contents may vary significantly. (Not available for packet flows.)

• Continuous Burst—a set of counted packets within a burst; the burst is repeated continuously. (Not available for packet flows.)

• Counted Burst (non-continuous) —a user-specified number of bursts per stream, where each burst contains a counted number of packets.

Each non-continuous stream is related to the next stream by one of four modes:

• Stop after this stream—data transmission stops after the completion of the current stream. (For example, after transmission of a stream consisting of 10 bursts of 100 packets each.)

• Advance to Next—data transmission continues on to the next stream after the completion of the current stream.



• Return to ID—after the completion of the current stream, a previous stream (designated by its Stream ID) is retransmitted once, and then trans-mission stops.

• Return to ID for Count—after the completion of the current stream, a pre-vious stream (designated by its Stream ID) is retransmitted for the user-specified number of times (count), and then transmission stops.

If a Continuous Packet or Continuous Burst stream is used, it becomes the last stream to be applied in a region, and data transmission continues until a Stop Transmit operation is performed.

A programmable Inter-Stream Gap (ISG) is applied before each stream, as pic-tured in Figure 3-6.

Figure 3-6. Inter-Stream Gap (ISG)

The size and resolution of the Inter-Stream Gaps depends on the particular Ixia module in use. There are no ISGs before Advanced Scheduler Streams. Refer to the Ixia Hardware Guide for specifications.

Bursts

Bursts are sets of a specified number of packets, separated by programmed gaps between the sets. For Ethernet modules, Inter-Burst Gaps (IBG) are inserted between the sets. For POS modules, bursts of packets are separated by Burst Gaps. The size and resolution of these gaps depends on the type of Ixia load mod-ule in use. Refer to the Ixia Hardware Guide for specifications. The placement of Inter-Burst Gaps is shown in Figure 3-7.

Figure 3-7. Inter-Burst Gap (IBG)/Burst Gap

Packets

Streams may contain a counted number of frames, or a continuous set of frames when Continuous Packet mode is used. Frames are separated by programmable

ISG Stream 1 ISG Stream 2 ISG Stream 3

Return to ID (Stream ID=2)

Advanceto next

Advanceto next

(Direction of Transmission)

ISG Burst of pkts IBG IBGBurst of pkts Burst of pkts IBG

Counted # of bursts or Infinite bursts (for Continuous Burst mode)



Inter-Packet Gaps (IPGs), sometimes referred to as Inter-Frame Gaps (IFGs). The size and resolution of the Inter-Packet Gaps depends on the particular Ixia module in use. Refer to the Ixia Hardware Guide for specifications. The place-ment of Inter-Packet Gaps is shown in Figure 3-8.

Figure 3-8. Inter-Packet Gap (IPG)

Frame Data

The contents of every frame and packet are programmable in terms of structure and data content. The programmable fields are:

• Preamble size (Ethernet only)—the size and resolution depends on the partic-ular Ixia load module used.

• Min Flag (POS only)—the minimum number of flag fields to precede the packet within the POS frame.

• Frame size—the size and resolution depends on the particular Ixia load mod-ule used.

• Destination and Source MAC Addresses (Ethernet only)—allows the MAC addresses to be set to constants, vary randomly, or increment/decrement using a mask.

• Data generators—five different data generators are available. These genera-tors are listed below, in order of increasing priority (from top to bottom). The values from generators located lower in this list override data from those higher in the list.

• Protocol-related data—formatted to correspond to particular data link, transport, and protocol conventions. Data link layer controls allow for Ethernet II and 802.3 SNAP formatting, with support for VLANs, MPLS, and Cisco-proprietary ISL. Protocol-specific data for formatting IPv4, IPv6, and IPX packets (such as Source and Destination IP addresses), as well as Layer 4 transport protocol headers (TCP/IP, IGMP, etc.) are also supported. IP Source and Destination addresses may be incremented or decremented using a network mask.

• Data patterns—can be one of three types: pre-defined patterns up to 8K bytes in length, randomly generated data, algorithmically generated data, or user-specified.

• High-speed 32-bit counters—four 32-bit counters. For some modules the counters can each be flexibly configured as multiple 16-bit and 8-bit counters. Each counter may independently increment or decrement using a mask.

• Frame Identity Record (FIR)—an identity record stored at the end of the packet. The information is very useful for determining the source of trans-mitted data found in capture buffers.

ISG Packet 1 IPG IPG IPG

Counted # of Packets or Infinite Packets (for continuous packet)

Packet 2 Packet 3



• Frame Check Sequence (FCS)—the checksum for a packet may be omit-ted, formatted correctly, or have deliberate errors inserted. Deliberate errors include incorrect checksum, dribble errors, and alignment errors.

PPP

Packet over Sonet cards also have the ability to perform PPP encapsulation. Refer to PPP Protocol Negotiation on page 3-32 for a complete discussion.

Transmit Operations

The transmit operations may be performed across any set of chassis, cards, and ports specified by the user. These operations are described in Table 3-1 on page 3-8.

Port Data Capture Capabilities

Most ports have an extensive buffer which may be used either to capture the packet data ‘raw’ as it is received, or to categorize it into groups known as Packet Groups. Each port must be designated to have a Receive mode which is either Capture or Packet Groups. Packet groups are used in determining latency, and are not available for most Type-3 or -M card modules; the exception is OC48c-M modules.

Table 3-1. Transmit Operations

Operation Usage

Start Transmit Starts the transmission operation on all ports included in the present set of ports. If no transmit operation has been performed yet, or if the last operation was Stop Transmit, then transmission begins with the first stream configured for each port. If a Pause Transmit operation was last performed, then transmission begins at the next packet in the queue for all ports.

Staggered Start Transmit

The same operation is performed as in Start Transmit, except that the start operation is artificially staggered across ports. The time interval between the start of transmission on consecutive ports is in the range of 25-30ms.

Stop Transmit Stops the transmission operation on all ports included in the present set of ports. A subsequent Start Transmission or Step Stream operation will commence from the first stream of each port.

Pause Transmit Stops the transmission operation on all ports in the present set of ports - at the end of transmission of the current packet. A subsequent Start Transmission or Step Stream will commence at the beginning of the next packet in the queue on each port.

Step Stream Causes one packet to be transmitted from each of the ports in the present set of ports.



The start of capture buffering may be triggered by a set of matching conditions applied to the incoming data, or all data may be captured. Packets can be filtered, as well. During capture mode operation, the amount of data saved in the capture buffer can be limited to a user-defined “capture slice” portion of each incoming packet, rather than the entire packet.

Each port’s Capture trigger and filter conditions are based on:

• Destination and Source MAC addresses (for Ethernet load modules)

• Data pattern match for the packet, and matching errors such as: Bad CRC, Bad Packet, Alignment Error, and Dribble Error.

• Packet sizes within a user-specified range.

Continuous vs. Trigger Capture

For some load modules, there are more advanced options provided for setting up data capture operations on a port. These options are set in the Receive Mode dia-log for the port. The available options are described below:

• Continuous Capture - Options are:

• All packets are captured.

• All packets which match a user-defined Capture Filter condition are cap-tured.

• Trigger Capture:

• Capture operation starts before a packet matching the user-defined Trigger condition is received. Options are:


• No packets are captured.

• All packets which match a user-defined Capture Filter condition are captured.

• Capture operation starts after a packet matching the user-defined Trigger condition is met. Options are:


• All packets which match a user-defined Capture Filter condition are captured.

• All packets which match the user-defined Trigger Capture condi-tion are captured.

• Trigger Position - The slider bar is used to set the position (% transmitted) in the data stream where the Capture Trigger will be first applied to incom-ing packets.



Port Capture Operations

The data capture operations may be performed across any set of chassis, cards, and ports defined by the user. These operations are described in Table 3-2 on page 3-10.

Forced Collision Operation

In addition to normal capture operation, forced collisions can be generated on the receive side of 10/100 load module ports, but only when the port is in half-duplex mode. (Note: This feature does not apply to 10/100 TXS8 ports.)

Forced collisions operate by generating ‘collision’ data as information is being received on the incoming port. The ‘collision’ takes the form of a number of nib-bles inserted at a user-specified offset within a packet as it is received. A period with a number of consecutive ‘collisions’ is followed by a period with no colli-sions. This combination of collisions and non-colliding periods can be repeated

Table 3-2. Capture Operations

Operation Usage

Start Capture Enables data capture on all ports in the set of ports whose Receive Mode is set to ‘Capture’. Packets are not actually captured until the user-specified Capture Trigger condition is satisfied.

Stop Capture Stops data capture on all ports in the set of ports.

Start Latency Initiates latency measurements for all ports in the set of ports whose Receive Mode is set to ‘Packet Group’ operation.

Stop Latency Stops latency measurements on all ports in the set of ports.

Start Collision Enables generation of forced collisions on received data, for all ports in the set of ports — if this option is selected for the port and enabled. Applies to half-duplex 10/100 Ethernet connections only.

Stop Collision Stops generation of forced collisions for all ports in the set of ports.



indefinitely, or repeated for a user-specified number of times. These parameters are shown in Figure 3-9 on page 3-11.

Figure 3-9. Forced Collisions

Packet Group Operation

Packet groups are sets of packets which have matching tags, called Group IDs. Real-time latency measurements within packet groups depend on coordination between port transmission and port reception. Each transmitted packet must include an inserted 4-byte packet group signature field, which triggers the receiv-ing port to look for the packet group ID. This allows the received data to be rec-ognized and categorized into packet groups for latency analysis. Note: Packet groups and latency measurements are not available for Type-3 and Type-M mod-ules.

After packet group operation is triggered on the receiving port, the packet group ID—a 2-byte field which immediately follows the signature—is used as an index by the port’s receive buffer to store information related to the latency of the packet. When packet group signatures and packet group ID’s are included in transmitted data, an additional time stamp is automatically inserted into the packet. Figure 3-10 shows the fields within packets which are important for packet grouping and latency analysis.

Figure 3-10. Packet Format for Packet Groups/Latency

Latency Measurements

There are two modes for latency measurement:

• Instantaneous - Latency measured for all received data (continuous). Up to 57,344 packet group IDs (PGIDs) may be used.

Non-CollidingPacketsColliding Packets Colliding Packets

PacketOffset

CollisionDuration

Preamble

Collision

(Individual Packet)

CRC/Time StampGroupSignature

Signature OffsetValue

Group ID Offset

ID FCS



• Latency over time - Latency measured for a number of time intervals of equal length, called “time buckets”. Figure 3-11 demonstrates the relation-ship between the time buckets and PGIDs in an example.

Figure 3-11. Multiple Latency Time Measurements - Example

The timeline is equally divided into a # of Time Buckets, each of which is ONE Time Bucket Duration in length. A time bucket duration can range anywhere from nanoseconds to hours, depending on the user configuration.

The maximum number of time buckets that can be handled is determined by the number of PGIDs in each bucket. The product of the number of time buckets and the number of PGIDs must be no more than 57,344. The number of PGIDs starts at 1 and increments by powers of 2—i.e., 2, 4, ..., up to 8192, and then jumps to 57,344.

Three types of latency measurements are available, corresponding to the type of device under test:

• Cut-Through—for use with switches and other devices that operate using packet header information. The time interval between the first data bit out of the Ixia transmit port and the first data bit received by the Ixia receive port is measured. The first data bit received on Ethernet links (10/100 and Gigabit modules) is the start of the MAC DA field. For Packet over Sonet links, the first bit received is the start of the IP header.

• Store and Forward—for use with routers and other devices that operate on the contents of the entire packet. The time interval between the last data bit out of the Ixia transmit port and the first data bit received by the Ixia receive port is measured. The last data bit out is usually the end of the FCS or CRC, and the first data bit received is as described above for Cut Through.

• Store and Forward Preamble (for Ethernet modules only)—as with store and forward, but measured with respect to the preamble to the Ethernet frame. In this case, the time interval between the last data bit out of the Ixia transmit port and the first preamble data bit received by the Ixia receive port is mea-sured. For this measurement, the size of the preamble (in bytes) is considered.

# of PGIDs/Time Bucket (8)

# of Time Buckets (5)

1 Time TIMELINE

2 3 4 510

1 2 3 4 5 6 7 8 Bucket

Total # of PGIDs = 8 x 5= 40 PGIDs

Note: The actual PGID numbers start at 0, and increase up to a maximum of 57,343.



Sequence Checking Operation

A number of ports have the additional ability to insert a sequence number at a user-specified position in each transmitted packet. This sequence number is dif-ferent and distinct from any IP sequence number within an IP header. On the receiving port, this special sequence number is retrieved and checked, and any out-of-sequence ordering is counted as a sequence error.

As in packet groups (see Packet Group Operation on page 3-11), for sequence checking a signature value is inserted into the packet on the transmit side to sig-nal the receive side to check the packet. In fact, this particular signature value is shared by both the packet group and the sequence checking operations. Both the signature value and sequence number are 4-byte quantities and must start on 4-byte boundaries. These fields are shown in Figure 3-12, in the order indicated by the default values in the Sequence Checking dialog.

Figure 3-12. Packet Format for Sequence Checking

Sequence numbers are integers which start at ‘0’ for each port when transmission is started, and increment by ‘1’ continuously until a Reset Sequence Index opera-tion is performed. Note that multiple sequence errors will result when a packet is received out of sequence. For example, if five packets are transmitted in the order 1-2-3-4-5 and received in the order 1-3-2-4-5, three sequence errors will be counted:

1. At 1-3, when packet 2 is missed.

2. At 1-3-2, when 2 is received after 3.

3. At 1-3-2-4, when 4 is received after 2.

Data Integrity Checking Operation

A number of ports also possess the ability to check the integrity of data contained in a received packet, by computing an an additional 16-bit CRC checksum. Note: Data Integrity Operations are not available for Type-3 cards.

As with packet groups (see Packet Group Operation on page 3-11) and sequence checking (see Sequence Checking Operation on page 3-13), a signature value is inserted into the packet on the transmitting interface, to serve as a trigger for the receiving port to notice and process the additional checksum. However, the data integrity operation uses a different signature value from the one shared by packet groups and sequence checking.

Note: Sequence checking operations are not available for Type-3, Type-M, or 10/100 load modules (except for 10/100TXS8).

CRC/Sequence Signature

Signature Offset

ValueSequence Number Offset

Number FCS



The end of the data integrity signature value marks the beginning of the range of packet data over which the 16-bit data integrity checksum is calculated, as shown in Figure 3-13. This packet data ends just before the timestamp and normal CRC/FCS. The CRC-16 checksum value must end on a 4-byte boundary. There may be 1, 2, or 3 bytes of zeroes (padding) inserted after the CRC-16, but before the Time Stamp, to enforce all boundary conditions.

Figure 3-13. Packet Format for Data Integrity Checking

When the Receive Mode for a port is configured to check for data integrity, received packets are matched for the data integrity signature value, and the addi-tional CRC-16 is checked for accuracy. Any mismatches are recorded as data integrity errors.

Port Statistics Capabilities

Each port automatically collects statistics. A wide range of statistics are pre-pro-grammed and available for many types of load modules. Other statistics may be selected or programmed and include:

• User-Defined Statistics—four counters which can be programmed to incre-ment based on the same conditions as those involved in defining capture trig-gers and capture filters.

• Quality of Service Types—separate counts for each of eight quality of service values used in IP headers.

• IP/UDP/TCP Checksum Verification—for hardware checksum verification.

• Data Integrity Stats—for errors relating to Data Integrity Operation. Refer to Data Integrity Checking Operation on page 3-13.

• Protocol Server Stats—protocol-based statistics for: ARP, BGP, ISIS, ICMP, OSPF, and RSVP-TE.

• SONET Extended Stats—statistics associated with SONET Line, Section and Path characteristics.

• Temperature Sensors Stats—for verifying that temperatures on high-perfor-mance 10 Gigabit and OC-192c POS cards are within operational limits.

Round Trip TCP Flows

For most 10/100 load modules, a special capability exists in the Ixia hardware to enable the measurement of round trip times for IP packets sent through a switch

CRC/

Data Integrity Packet DataCRC-16

TimeStamp

Signature Offset

Data Integrity

Data IntegritySignatureValue

for Checksum

FCS



or other network device. The normal setup for this measurement is shown in Figure 3-14.

Figure 3-14. RoundTrip TCP Flows Setup

In this scenario, Ports A and X are configured on one IP subnet, and Ports B and Y are configured on a different IP subnet. IP packets sent from A have a source address of A and destination address of B. The DUT is configured to route or for-ward to Y any packets that it receives on X for an address on B-Y’s subnet. After being received on Port B, the packet is reconstructed in a modified form (described below), and sent back in the opposite direction along the path to Port A.

When enabled on the Ixia receiving port (in this case, Port B), the Round Trip TCP Flows feature performs several operations on the received IP packet:

• The Source and Destination IP addresses are reversed, and a packet destined for Port A is created using the reversed addresses.

• The frame size, source and destination MAC addresses, and background data pattern are set as specified by the user.

• The timestamp is copied to the new packet unmodified.

• The new packet is transmitted to Port Y on the DUT, and should be routed back to Port A by the DUT.

This re-assembly/retransmit process makes it possible to measure the round-trip time for the packet’s trip from Port A through the DUT to Port B, and back through the DUT to Port A again. Note that the Packet Groups feature may be used, in addition, for latency measurements on this round trip. For latency test-ing, the background data set by the Round Trip TCP Flows feature will overwrite the Packet Group Signature Value contained in the packet. It is important that proper programming of the background data pattern be used to insert the appro-priate signature value back into the packet.

Protocol Server Each port in an Ixia chassis operates a Protocol Server. The Protocol Server includes a complete TCP/IP stack, allowing different forms of high-level DUT testing. The Protocol Server can be configured to test a set of provided Level 2 and Level 3 protocols, which include MAC and IP addressing and IP routing. The Protocol Server for Packet over SONET cards omits all MAC configuration

Ixia Ports

A

B

DUT Ports

X

Y



items, since POS does not use a MAC layer. The information gathered by the Protocol Server is used within generated frame data, as well.

The Protocol Server is accessed through the Protocol Server window.The follow-ing protocols are supported by the Protocol Server.

Each protocol must be individually enabled for a selected port in the Protocol Window, as described in Table 3-3 on page 3-16. Even when a service is enabled, the DUTs must be listed in the IP table in Protocol Window.

IP IP to MAC addressingARP Address Resolution Protocol (non-POS only)IGMP Internet Gateway Management ProtocolBGP4 Border Gateway ProtocolOSPF Open Shortest Path First routing protocolRIP Routing Information ProtocolRIP Intermediate System to Intermediate System, Dual ModeRSVP-TE Resource Reservation Protocol for Traffic Engineering

Table 3-3. Enabled Services in the Protocol Window

Service Usage

ARP (Non-POS cards only) Enables ARP requests and responses. ARP requests are received at the MAC level. See ARP on page 3-17.

Ping Enables PING transmission and reception. Ping messages are ICMP messages of type Echo Request. Responses are ICMP message of type Echo Response. The protocol server, however, responds to all ICMP messages. Once enabled for a port in Protocol Window, the Ping function may be used directly via the port listing in the Network Resources window.

IGMP Enables IGMP testing. IGMP messages are sent as IP protocol number 2. See IGMP on page 3-17.

BGP4 Enables BGP4 testing. BGP4 is carried on TCP port 179. The Protocol Server optionally opens a connection with designated peers and maintains those connection. See BGP4 on page 3-19.

OSPF Enables OSPF testing. OSPF messages are sent as IP protocol number 89. See OSPF on page 3-17.

RIP Enables RIP testing. RIP messages are sent as UDP messages on port 520. See RIP on page 3-23.

IS-IS Enables IS-IS testing. IS-IS messages are sent using ISO messages. See IS-IS on page 3-24.

RSVP-TE Enables RSVP-TE testing. RSVP messages are sent as raw IP messages using protocol number 46. See RSVP-TE on page 3-27.



IP

The IP table specifies a per port correspondence between IP addresses, MAC addresses (for Ethernet ports only), and the Default Gateway. IP addresses may be expressed as individual addresses or as a range of addresses.

All ARP requests (for Ethernet) are sent to the Default Gateway address. In most cases, the Default Gateway Address is the address of the DUT. When a gateway separates the Ixia port from the DUT, use the IP address of that gateway as the Default.

ARP

The Address Resolution Protocol (ARP) facility controls the manner in which ARP requests are sent. This option is only available on Ethernet load modules. The resulting responses from ARP requests are held in the ARP Table, which is used to set MAC addresses for transmitted data. ARP’ing the DUT allows tests and generated frames to be configured with a specific IP address, which at run time is associated with the MAC address of that particular Device Under Test.

IGMP

The Internet Group Management Protocol (IGMP) is used to control the handling of group membership in an Internet. Version 1 of the protocol is specified in RFC 1112, and Version 2 is specified in RFC 2236). The Ixia hardware generates both Version 1 and Version 2 messages.

IGMP normally works in an environment in which there are a number of IGMP-capable hosts connected to one or more IGMP routers. The routers forward mem-bership information and packets to other IGMP routers and receive group mem-bership information and packets from other IGMP routers.

The Ixia hardware simulates one or more hosts while the DUTs are assumed to be IGMP routers. The simulation calls for groups of simulated hosts to respond to IGMP router-generated queries and to automatically generate reports at regular intervals. A number of IGMP groups are randomly shared across a group of hosts.

OSPF

Open Shortest Path First (OSPF) is a set of messaging protocols that are used by routers located within a single Autonomous System (AS). The Ixia hardware simulates one or more OSPF routers for the purpose of testing one or more DUT routers configured for OSPF. The OSPF specification (RFC 2328) details the message exchanges by OSPF routers, as well as the meanings and usage.

OSPF has three principal stages:

• The HELLO Protocol

• Database transfer



• HELLO Keepalive

When an OSPF router initializes, it sends out HELLO packets and learns of its neighboring routers by receiving their HELLO packets. If the router is on a Point-to-Point link, or on an Ethernet (transit network) link, these packets will be addressed to the AllSPFRouters multicast address (224.0.0.5). In these types of networks, there is no need to manually configure any neighbor information for the routers.

Each router that is traversed on the path between neighbors is added to a list con-tained in the HELLO packet. In this way, each router discovers the shared set of neighbors and creates individual state machines corresponding to each of its neighbors.

If the network type is broadcast, then the process for selecting a Designated Router (DR) and Backup Designated Router (BDR) begins. A Designated Router is used to reduce the number of adjacencies required in a broadcast network. That is, if no Designated Router is used, then each router must pair (form an adja-cency) with each of the other routers. In this case, the number of required adja-cencies is equal to the square of the number of routers (N^2). If a DR and BDR are used, the number of required adjacencies drops to 2 times the number of rout-ers (2N). Currently, the Ixia ports are unable to simulate a DR or BDR.

Once the routers have initialized their adjacency databases, they synchronize their databases. This process involves one router becoming the master and the other becoming the slave. On Ethernet networks, the DR is always the master; on point-to-point networks, the router with the highest Router ID is the master.

Link State Advertisements (LSAs) are OSPF messages that describe an OSPF router’s local environment. The simplest LSA Type is the router-LSA (Router-Links LSA). Each router is required to generate exactly one of these LSAs in order to describe its own attached interfaces. If a network that consists of a single OSPF area is being simulated with only point-to-point links and there are no Autonomous System Border Routers (ASBR), then this is the only type of LSA that will be sent.

The slave asks the master for its LSA (Link State Advertisement) headers, which enables the slave to determine the following information:

1. The subset of LSAs that the master holds, but that the slave does not have, and

2. The subset of LSAs that the master and slave both have, but which are more recent on the master.

The slave router then proceeds to explicitly query the master to send it each LSA from Steps (1) and (2). The slave sends an ACK to the master upon receipt of each LSA. The global Link State Database (LSDB) is constructed by each router, based on LSAs from all the other routers in the network.

Once this exchange process is complete, the routers are considered to have reached Full Adjacency, and each will run the link state algorithm to update its IP forwarding tables. The routers continue to exchange periodic HELLO packets, as



keep-alive messages, until a change occurs (e.g., a link goes down or an LSA expires). OSPF routers continue to periodically exchange their LSAs every 30 minutes to ensure they all hold identical LSDBs.

This section describes the programming of the Ixia hardware related to OSPF testing, as well as the theory of operation and protocol message formats. The Ixia hardware will simulate multiple OSPF routers on multiple networks. For exam-ple, in Figure 3-15 there are three networks and three routers.

Figure 3-15. Sample OSPF Network

The Protocol Server calls for the specification of router-network connections to be specified in a network-centric fashion. One specifies the network in terms of an Area ID and network mask. One specifies the routers in terms of the interface IP address on that network and Router ID — usually the lowest IP address for the router. For the sample OSPF network, in which Router 3 is the DUT, the three networks are specified by their significant characteristics as shown in Table 3-4.

Within this framework, Link State Advertisements (LSAs) may be issued from the perspective of any interface on any router. Any OSPF messages from the DUT Routers may be captured and analyzed in the normal manner.

BGP4

Border Gateway Protocol Version 4 (BGP-4) is the principal protocol used in the Internet backbone and in networks for large organizations. The BGP4 specifica-tion (RFC 1771) details the messages exchanged by BGP routers, as well as their

Network 1192.168.36.0/24

Network 2172.16.1.0/24

OSPF.10

OSPF.20

Network 310.10.10.0/24

.40

.41

.90

Ixia Ports Device Under Test

Router 1

Router 2

OSPFRouter 3(DUT)

Ixia-Sim.

Ixia-Sim.

Table 3-4. Sample OSPF Network Assignments

Network Area ID Network Mask Router ID Router Interface IP Address

1 192.168.36.0 255.255.255.0 192.168.36.10 10.0.0.40

2 172.16.0.0 255.255.255.0 172.16.0.20 10.0.0.41

3 10.0.0.0 255.255.0.0 10.0.0.4010.0.0.4110.0.0.90

10.0.0.4010.0.0.4110.0.0.90



meaning and usage. BGP4 - Inter-Domain Routing in the Internet, by John W. Stewart III is a descriptive reference on this protocol.

Internal Versus External BGP

The BGP4 protocol is used according to two sets of rules, depending on whether or not the two routers communicating are within the same Autonomous System (AS). An AS is a collection of routers that implement the same routing policy and are typically administered by a single group of administrators. ASs connected to the Internet are assigned Autonomous System Numbers (ASNs) which are key to inter-domain routing. When BGP is used between two ASs, the protocol is referred to as EBGP (External BGP); when BGP is used within an AS it is referred to as IBGP (Internal BGP). Figure 3-16 depicts the differences in topol-ogy between EBGP versus IBGP.

Figure 3-16. EBGP versus IBGP Usage

In the figure above, AS1, AS2, and AS3 are distinct Autonomous Systems. The Rns are routers in the various ASs. Routers on the links between ASs ‘speak’ EBGP, while the routers within AS3 ‘speak’ IBGP.

IBGP Extensions

In the original BGP4 specification, all IBGP routers within an AS were required to establish a full mesh with each other. This led to a lack of scalability which was solved by the introduction of two additional concepts: route reflection and confederation.

In route reflection, some routers in an AS are assigned the task of distributing internal routes to other internal AS routers. In order to prevent looping within an AS that uses route reflection, two concepts are important: originator-id and clus-ter-list. The originator-id is the identification of the router that originated a par-ticular route; routers within an AS propagate this information and refuse to send a route back to its originator. Even the use of reflectors and originator-ids can lead to scalability problems in an AS. The cluster-list concept helps this problem. A cluster consists of a reflecting router and its clients. A Cluster ID is the IP address of the reflecting router if there is one, or a configured number otherwise. A cluster-list is a constructed list, consisting of the cluster IDs of all of the clus-ters that a route has passed through. Each router will refuse to send a route back to a cluster that has seen the route already.

AS1 AS2

AS3

R1 R2

R4R3

R5

EBGP

IBGP



In a confederation, an AS is divided into multiple sub-confederation subsets. Each sub-confederation is defined in terms of its own ASN and a list of routers. Routers within a sub-confederation are expected to fully mesh using IGP. Sub-confederations within a confederation speak a variant of EGP, called EIGP. Additional path attributes are used with a confederation to indicate paths that should not be propagated outside the confederation.

Communities

In deployment of BGP4 into a growing Internet environment, it became neces-sary to deal with certain routes in different manners not related to the strict rout-ing of packets. The community attribute was invented to allow a route to be ‘tagged’ with multiple numbers, called communities. This is also referred to sometimes as route coloring.

BGP Router Test Configuration

The Ixia Protocol server implements an environment in which the Ixia hardware simulates multiple routers which speak IBGP and/or EBGP with one or more DUT routers. For example, in Figure 3-16, the Ixia hardware simulates R1, R3, and R5 while the DUTs are R2 and R4. Figure 3-17 (below) depicts the same setup based on the location of the simulated or actual router:

Figure 3-17. BGP Interconnection Environment

All of the routers are logically connected through appropriate networking hard-ware. The Ixia hardware is used to simulate three of the routers in two different ASs communicating with two routers being tested.

A single router simulated by the Ixia hardware is specified by a single IP address and a number of simulated routers may be specified by a range of IP addresses. Each DUT router is identified by its IP address.



Messages may be sent between the simulated routers and the DUT routers when a connection is made and one of the two endpoints sends an OPEN message. Where the simulated and the DUT routers send their OPEN messages simulta-neously, standard collision handling is applied. Thereafter, the simulated routers send a number of UPDATE messages to the DUT routers. The UPDATE mes-sages contain a number of network address ranges (route ranges), also known as ranges of prefixes. The ranges of network addresses generated is illustrated in Figure 3-18.

Figure 3-18. Generation of Network Addresses in BGP UPDATE Messages

A designated number of network addresses are generated with network Mask Width from the From through To values. Table 3-5 shows some examples of gen-erated addresses. Network Addresses are generated by starting with the First Route and From mask width up to, but not including 224.0.0.0. (127.*.*.* is also skipped). If the requested number of network addresses has not been generated

First rangethru

Network Address (32 bits)0 32

generate all network addresses in this range first,

then all network addresses in this range,

and finally all network addresses in this range last



before 224.0.0.0 is reached, then the next mask length is used to generate net-work addresses.

All of the generated network addresses are associated with a set of attributes that describes routing to these generated network addresses and associated features.

A variable number of withdrawn routes may be packed into each UPDATE mes-sage. The packing is randomly chosen across a range of a number of routes. Only one route can be added per UPDATE message. The time interval between UPDATE messages is configurable, in units of milliseconds.

A BGP4 network condition called ‘flapping’ can be simulated by the protocol server on an Ixia port. In Link flap, a peer BGP router appears to be going repeat-edly offline and online, which is accomplished on the Ixia port by alternate dis-connects and reconnects of the TCP/IP stack. In Route flap, BGP routes are repeatedly withdrawn, and then readvertised, in UPDATE messages.

RIP

The Routing Information Protocol (RIP) is an interior routing protocol. It is the oldest and most frequently used of the LAN routing protocol. RIP routers broad-cast or multicast to each other on a regular basis and in response to REQUEST

Table 3-5. Examples of Generated BGP Routes (Network Addresses)

First Route Mask Width From

Mask WidthTo

Number of Routes

Generated BGP Routes(Network Addresses)

192.168.36.0 24 26 3,613,852,672 192.168.36.0/24192.168.37.0/24192.168.38.0/24...223.255.255.255/24224.0.0.0+ skipped192.168.36.0/25192.168.36.128/25192.168.37.0/25...223.255.255.255/25224.0.0.0+ skipped192.168.36.0/26192.168.36.64/26192.168.36.128/26...223.255.255.255/26

204.197.56.0 24 24 4 204.197.56.0/24204.197.66.0/24204.197.76.0/24204.197.86.0/24



packets. RIP routers incorporate routing information received from their neigh-bors into their own routing table and forward them on to other neighbors. Two distinct versions of RIP exist: version 1 and version 2. Both IPv4 and IPv6 are supported.

As implemented by the Protocol Server, each Ixia port is capable of simulating one or more routers at distinct addresses. Routing tables for the simulated routers are configured by the user and sent out at regular intervals, with a configurable randomizing factor. Either version 1 or version 2 packet formats may be sent via multicast or broadcast (for compatibility with version 1 routers). Received pack-ets may be filtered for version 1 and/or 2 compatibility.

The current implementation of the Protocol Server uses Split Horizon with Space Saver as its update mode, which will receive, but not process RIP broadcasts heard from DUT routers. That is, it will not incorporate received information into its own table, but rather always broadcast the same routing table. Future versions will offer Split Horizon, Split Horizon with Poison Reverse and Silent modes of update.

The Protocol Server will, however, respond to REQUEST packets that it receives. Two types of requests are processed:

• Request for all routes. The Protocol Server will send the same routing table that it sends at regular intervals back to the requestor.

• Request for specific routes. The Protocol Server will fill in the requested information in the received packet and send it back to the requestor.

IS-IS

The Intermediate System to Intermediate System Routing protocol was originally designed for use with OSI Connectionless Network Protocol (CLNP) and is defined in ISO 8473. It was later extended to include IP functions in IETF RFC 1195. When routing for OSI and IP packets (defined in ISO/IEC 10589:1992(E)) is combined in this way, the protocol is referred to as Integrated IS-IS or Dual IS-IS.

Many OSI concepts are needed to understand IS-IS. The following terms are important to the following discussion:

• IS – Intermediate System. A router is an IS.

• ES – End System. A host is an ES. The Ixia hardware does not currently sim-ulate End Systems.

• PDU – Protocol Data Unit. A data unit used within IS-IS protocol description. The following specific PDUs are used in IS-IS communications:

• LSP – Link State PDU. This message holds the significant part of the rout-ing table sent between routers.

• IIH – IS-IS Hello PDU. This message is used between ISs to discover neighbors and maintain state.



• SNP – Sequence Number PDU. This message is used to request LSPs and acknowledge receipt of LSPs. Two types are used depending on the net-work type:

• CSNP – Complete SNP. In broadcast networks, these are sent by the Des-ignated Router in an area. In point-to-point connections, CSNPs are used for initialization. A CSNP contains a complete description of the LSPs in the sender’s database.

• PSNP – Partial SNP. On broadcast networks, PSNPs are used to request LSPs. On point-to-point connections, PSNPs are used to acknowledge receipt of LPSs. On both types of networks, PSNPs are used to advertise newly learned LPSs or purge LPSs. A PSNP contains a subset of the received records.

IS-IS areas are administrative domains which contain IS-IS routers, have one or more private networks, and may share networks with other areas. One or more Area IDs are associated with an area. Most areas only require one ID during steady state operation, but up to three IDs may be needed during the process of migrating a router from one area to another. In most cases, the maximum number of area IDs is set to three.

IS-IS routers can be divided into three categories, as follows:

• Level 1 (L1) – these routers have no direct connection to any other IS-IS area. They can connect only to L1 or L1/L2 routers within their own area.

• Level 2 (L2) – they are used as backbone routers in the routing domain, to connect IS-IS areas. They can connect only to other L2 routers outside their area, or to L1/L2 routers within their own area.

• Level 1/2 (L1/L2) – these routers have interfaces which can connect to both L1 routers within their own area, and to L2 routers in other areas.

Entirely separate routing tables are maintained for Level 1 and Level 2 IS-IS information, even within L1/L2 routers. All L1s within an area maintain identical databases. All L2s maintain identical databases, and no L2 routes are advertised to L1 routers.

The example shown in Figure 3-19 on page 3-26 consists of a theoretical IS-IS topology, including a possible IS-IS test scenario in which one of the L2 back-bone routers is the DUT (pictured in bold within Area C). The Ixia Protocol Server simulates the IS-IS routers which are directly connected to the DUT (L2 in Area C, and an L1/L2 in Area B). Appropriate PDUs are sent to the DUT from the two Ixia-simulated routers (pictured in bold, dashed lines in Figure 3-19). Note that, as shown in this diagram, all IS-IS routers are considered to reside entirely within an area, unlike some other protocols such as OSPF, where routers can reside at the edges of domains.



Figure 3-19. IS-IS Areas

Due to the OSI derivation of the IS-IS protocol, each IS-IS router has an OSI NET address of between 8 and 20 octets. The NET address consists of two parts: an Area ID and a System ID. The Area ID has a number of different formats defined in OSI specifications. The System ID may be from 1 to 8 octets in length The default System ID length defaults to 6 octets and must be the same length for every router in the domain. The System ID is unique within its area for Level 1, or unique within the routing domain for Level 2 or Level 1/2. Two types of net-work connections are supported: broadcast and point-to-point. In a broadcast net-work, each interface on an IS-IS dual-mode router must have an IP address and mask.

IS-IS routers maintain knowledge of each other by exchanging Hello PDUs at regular, configurable Hello intervals. A router is considered down if it does not respond within a separately configurable Dead interval.

In the IS-IS protocol, for each of the levels (L1 or L2) one of the routers is elected as the Designated Router (DR), based on priority values assigned to each interface as part of Hello PDU processing. The Ixia Protocol Server does not sup-port the role of DR, so to ensure that it is not elected by its IS-IS peers each Ixia-simulated IS-IS router has a default priority of “0”, indicating its unwillingness to be the DR.

IS-IS routers update each other using Link State PDUs (LSPs) at a regular inter-val of 30 minutes. The LSP header contains the Remaining Lifetime for the LSP, a Sequence Number, and a checksum. In a Point-to-Point network, the receiving router sends a Partial Sequence Number PDU (PSNP). In a Broadcast network, the Designated Router sends a Complete Sequence Number PDU (CSNP).

Each LSP contains information about a router’s connection to local networks, plus a metric related to each network. ISO DP 10589 defines four types of met-

L1

L1

L1/L2

L2

L1

L1

L1/L2

L2

L2

L1/L2

L1L1

Area A

Area B

Area C

Area D

Ixia

Ixia

DUT



rics: default, delay, expense, and error. Only the default type is currently imple-mented in most routers and by the Ixia Protocol Server.

RSVP-TE

The Ixia protocol server implements a part of the Resource Reservation Protocol (RSVP) used for Traffic Engineering (TE). This subset of the RSVP protocol, referred to as RSVP-TE, is used in the process of constructing a path through a sequence of MPLS-enabled label switched routers (LSRs), while reserving nec-essary bandwidth resources. The use of an internal gateway routing protocol (IGP), such as OSPF, is also required to automatically determine the “next hop” router.

Multi-Protocol Label Switching (MPLS) allows rapid forwarding of packets across a sequence of routers, without time-consuming examination of the packet contents at each hop. Label switching has been used extensively for ATM traffic, where overhead bytes for each “cell”, or packet, of data constitute a large per-centage of the overall data transmitted. The addition of a “label” value to the header information in each cell or packet supplies the only forwarding informa-tion required to transit the MPLS domain. Based on information in its forwarding table, each LSR replaces (swaps) the incoming label with a new one which will direct the packet to the next hop.

The most important output from an RSVP-TE setup session is the set of MPLS labels, which are used by the MPLS-enabled routers along the path to efficiently forward network traffic. The operation of RSVP-TE is shown in Figure 3-20.

Figure 3-20. RSVP-TE Overview

Through the use of RSVP-TE message exchanges, the router at the entry to the MPLS domain, also known as an Ingress LSR, initiates the creation of a dynamic ‘tunneled’ pathway to the Egress LSR, the router at the exit side of the MPLS domain. Packets which pass through this “tunnel” are essentially “protected” from the extensive packet processing normally imposed by each router it

LSRs

LSR I LSR II

LSRs

SenderRouters

DestinationRouters

A 1

PATH Messages

RESV Messages

Tunnel 1

Tunnel 2

LSPs 1, 2, 3

LSPs 1, 2, 3

2

3

B

C

D



traverses. Once this special pathway or Label Switched Path (LSP) is established, the router can forward, rather than route, packets across the domain, saving con-siderable processing time at each intermediate LSR (Transit LSR). The resulting tunneled pathway is known as an LSP Tunnel. The traffic flows through the LSP Tunnels are uni-directional. To establish bi-directional traffic through the MPLS domain, a second LSP Tunnel must be created in the opposite direction.

An LSP Tunnel is defined by a Destination Address (the IP address of the Egress LSR), and a Tunnel ID. At a finer level of granularity are LSP IDs. Essentially, these LSP IDs can serve to provide a set of aliases for alternate hop-by-hop paths between a single pair of Ingress and Egress LSRs, and therefore exist within the same LSP Tunnel.

Note: Ingress and Egress LSRs are also known as Label Edge Routers (LERs).

Two principal RSVP message types are used to establish LSP Tunnels:

• PATH message. A PATH message is generated by the ingress router and sent toward the egress router. This is termed the downstream direction. This PATH message is a request by the sending LSR for the establishment of an LSP to the egress router. Each LSR in the path to the destination router digests the PATH message and does one of three things:

• If the LSR cannot accommodate the request, it rejects the request by send-ing a PATH_ERR message back to the source indicating the nature of the rejection.

• If the LSR is not the egress router, it sends a PATH message to the next LSR toward the destination router.

• If the LSR is the egress router, it should respond with a RESV message back to its most recent neighbor.

• RESV message. A RESV message is generated by the egress router and sent over the reverse path that the PATH messages took. This is termed the upstream direction.

An additional HELLO message is used between neighbor LSRs to ensure that LSRs are alive. This allows for quick tunnel replacement in the case of link or router failure.

A set of labels is passed in the RESV messages sent upstream from the egress to the ingress router. A label is sent from one LSR to its upstream neighbor telling the upstream router which label to use when later sending downstream traffic.

Three scenarios are currently supported to test MPLS/RSVP-TE on a DUT using Ixia equipment:

1. The DUT acts as the Ingress LSR, and the Egress LSR is simulated by an Ixia port.

2. The DUT acts as the Egress LSR, and the Ingress LSR is simulated by an Ixia port.

3. The DUT acts as a Transit/Intermediate LSR, and the Ingress and Egress LSRs are simulated by Ixia ports.



PATH Messages

PATH messages contain a number of objects which define the tunnel to be estab-lished. These are shown in Table 3-6.

Explicit_Route

An explicit route is a particular path in the network topology. Typically, the explicit route is determined by a node with the intent of directing traffic along that path. An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the

Table 3-6. RSVP-TE PATH Message Objects

Object Contents Usage

SESSION Describes the destination router and associates a tunnel ID with the session.

tunnel endpoint The destination router’s IP address.

tunnel ID A unique LSP tunnel ID.

SENDER_TEMPLATE The description of the sender.

tunnel sender address

The sender router’s IP address.

LSP ID A unique LSP ID.

LABEL_REQUEST Asks all the LSRs to send back label values via RESV messages.

SENDER_TSPEC andADSPEC

Both of these objects deal with bandwidth and other QoS requirements for the path.

TIME_VALUES Timing values related to the refresh of tunnel information.

refresh interval The interval between messages.

EXPLICIT_ROUTE Allows the sender to request that the LSP tunnel follow a specific path from ingress to egress router. See Explicit_Route on page 3-29 for more details.

SESSION_ATTRIBUTE Other attributes associated with the session: tunnel establishment priorities, session name and optionally resource affinity.

RSVP_HOP Describes the immediate upstream router’s address to the downstream router.



path. Each group of nodes is called an abstract node. Thus, an explicit route is a specification of a set of abstract nodes to be traversed.

There are three types of objects in an explicit route:

• IPv4 prefix

• IPv6 prefix

• Autonomous system number

Each node has a loose bit associated with it. If the bit is not set, the node is con-sidered strict. The path between a strict node and its preceding node may only include network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding node may include other network nodes that are not part of the strict node or its preceding abstract node.

RESV Message

The RESV message contains object that indicate the success of the PATH request and the details of the assigned tunnel. These are shown in Table 3-7.Table 3-7. RSVP-TE RESV Message Objects

Object Usage

SESSION Indicates which session is being responded to.

TIME_VALUES As in the PATH message but from the downstream LSR to the upstream LSR.

STYLE The type of reservation assigned by the egress router. This relates to whether individual tunnels are requested for each sender-destination connection or whether some connections may use the same tunnel.

FILTER_SPEC The sender router’s IP address and the LSP ID.

LABEL The label value assigned by the downstream router for use by the upstream router.

RECORD_ROUTE If requested, the complete route from the destination back to the source. The contents of this object include the IP addresses in either v4 or v6 format of all the LSRs encountered in the formation of the LSP, and optionally the labels used at each step. Each LSR on the upstream path prepends it’s own address information.

RESV_CONF If present, it indicates that the ingress router should send a RESV_CONF message in response to the destination to indicate that the tunnel has been completely established.



Other Messages

Several additional messages are used in RSVP-TE, as explained in Table 3-8.

Ixia Test Model

The Ixia test process is designed so as to fully exercise RSVP functionality in MPLS routers. An Ixia port can simulate any number of LSR routers at the same time. Each router operates in an ingress or egress mode. In the following discus-sion, LSRs I and II refer to Figure 3-20:

• Ingress mode – LSRs I and II are termed a neighbor pair, where LSR I is the upstream router being simulated and LSR II is its immediate downstream neighbor. The Ixia port generates the PATH and HELLO messages that LSR I would send. LSR II is the Device Under Test (DUT) and may be an egress router or be connected to other LSRs, as shown in the figure.

• Egress mode – the Ixia port simulates LSR II while LSR I is the DUT. The Ixia port interprets PATH messages that it receives to determine if they are directed for any of the defined destination routers. If that is the case, it responds with appropriate RESV messages.

If requested, HELLO messages are generated and responded to in either mode.

When the Ixia port operates in Ingress mode, it attempts to set up LSP tunnels for each combination of sender router and destination router, using any number of LSP tunnels and any number of LSP IDs for each LSP tunnel. Thus the number of PATH messages that the Ixia port will attempt to generate for each refresh interval is:

# of sender routersx # of destination routersx # of LSPsx # of LSP tunnels

Table 3-8. Additional RSVP-TE Messages

Message Usage

PATH_ERR Any LSR may determine that it cannot accommodate the tunnel requested in a PATH message. In this case it sends a PATH_ERR message back to the sender.

PATH_TEAR When a sender router determines that it wants to tear down a tunnel, it sends a PATH_TEAR message to the destination router.

RESV_ERR If a router cannot handle a reservation, it sends a RESV_ERR back to the destination router.

RESV_TEAR When a destination router determines that it wants to tear down a tunnel, it sends a RESV_TEAR message upstream to the source router.

RESV_CONF When requested, a sender router will respond to the destination router with a RESV_CONF message to indicate that a complete tunnel has been successfully established.



The protocol server records all labels and other information that it receives on behalf of its simulated routers and displays those in a convenient format.

PPP Protocol Negotiation

The Point-to-Point Protocol (PPP) is available on all of the Ixia Packet over Sonet (POS) ports. The Point-to-Point Protocol (PPP) is widely used to establish, configure and monitor peer-to-peer communication links. A PPP session is estab-lished in a number of steps, with each step completing before the next one starts. The steps, or layers, are:

1. Physical – a physical layer link is established.

2. Link Control Protocol (LCP) – establishes the basic communications parame-ters for the line, including the Maximum Receive Unit (MRU), type of authentication to be used and type of compression to be used.

3. Link quality determination and authentication. These are optional processes. Quality determination is the responsibility of PPP Link Quality Monitoring (LQM) Protocol. Once initiated, this process may continue throughout the life of the link. Authentication is performed at this stage only. There are multiple protocols which may be employed in this process; the most common of these are PAP and CHAP.

4. Network Control Protocol (NCP) – establishes which network protocols (such as IP, OSI, MPLS) are to be carried over the link and the parameters associ-ated with the protocols. The protocols which support this NCP negotiation are called IPCP, OSINLCP and MPLSCP, respectively.

5. Network traffic and sustaining PPP control. The link has been established and traffic corresponding to previously negotiated network protocols may now flow. Also, PPP control traffic may continue to flow, as may be required by LQM, PPP keepalive operations, etc.

All implementations of PPP must support the Link Control Protocol (LCP), which negotiates the fundamental characteristics of the data link and constitutes the first exchange of information over an opening link. Physical link characteris-tics (media type, transfer rate, etc.) are not controlled by PPP.

The Ixia PPP implementation supports LCP, IPCP, MPLSCP, and OSINLCP. When PPP is enabled on a given port, LCP and at least one of the NCPs must complete successfully over that port before it will be administratively “up” and therefore be ready for general traffic to flow.

Each Ixia POS port implements a subset of the LCP, LQM, and NCP protocols. Each of the protocols is of the same basic format. For any connection, separate negotiations are performed for each direction. Each party sends a Configure-Request message to the other, with options and parameters proposing some form of configuration. The receiving party may respond with one of three messages:

• Configure-Reject – the receiving party doesn’t recognize or prohibits one or more of the suggested options. It returns the problematic options to the sender.

• Configure-Nak – the receiving party understands all of the options, but finds one or more of the associated parameters unacceptable. It returns the prob-lematic options, with alternative parameters, to the sender.



• Configure-Ack – the receiving party finds the options and parameters accept-able.

For the Configure-Reject and Configure-Nak requests, the sending party is expected to reply with an alternative Configure-Request.

The Ixia port may be configured to immediately start negotiating after the physi-cal link comes up, or passively wait for the peer to start the negotiation. Ixia ports will both send and respond to PPP keepalive messages – called echo requests.

LCP – Link Control Protocol Options

The following table outlines the parameters associated with the Link Control Pro-tocol. LCP includes a number of possible command types, which are assigned option numbers in the pertinent RFCs. Note that PPP parameters are typically independently negotiated for each direction on the link. The “Negotiate” column indicates how Ixia’s present implementation handles each option/parameter dur-ing the negotiation process. “Full” means that full, bi-directional negotiation is supported. “Reject” indicates that the option is not supported, and a option rejec-tion will be sent if the peer attempts to negotiate the option. A check in the “User Access” column means user control is provided for the option via IxExplorer or the Tcl/C++ APIs. Numerous RFCs are associated with LCP, but the most impor-tant RFCs are RFC 1661 and RFC 1662. The HDLC/PPP header sequence for LCP is FF 03 C0 21. Notes on key parameters follow the table Table 3-9 on page 3-33.Table 3-9. PPP-LCP Options

LCP Option

Option Name or Parameter

Purpose RFC Negotiate User Access

0x00 Vendor Extensions Allow exchange of proprietary information between devices of same vendor.

2153 Reject No

0x01 Maximum Receive Unit

Specify maximum supported size for PPP information field. See Maximum Receive Unit on page 3-36 for more details.

1661 Full Yes



0x02 Asynchronous Control Character Map (ACCM)

Allow independent select/deselect of each character in range 0x00 thru 0x1F as a control character. See Asynchronous Control Character Map on page 3-37 for more details.

1662 Full (synchronous only)

Yes

0x03 Authentication Protocol

Specify which protocol (PAP, CHAP, etc.) will be used during a subsequent authentication phase.

1661 Reject No

0x04 Quality Protocol Specify which protocol will be used for tracking link performance. Link-Quality Report is the only standard option supported.

1661 Full Yes

0x05 Magic Number Specify random tag used to detect loop-backs and to identify peers. See Magic Number on page 3-37 for more details.

1661 Full Yes

0x06 Protocol Field Compression (PFC)

Indicate whether reception of compressed PPP protocol fields (one byte instead of two) is supported.

1661 Reject No

0x07 Address and Control Field Compression (ACFC)

Indicate whether reception of compressed HDLC headers (without address and control fields) is supported.

1661 Reject No

Table 3-9. PPP-LCP Options

LCP Option





0x08 FCS Alternatives Specify CRC type (16 or 32 bit).

1570 Reject No

0x09 Self Describing Pad (SDP)

Allow padding of PPP information field to a specified boundary.

1570 Reject No

0x0A Numbered Mode Specify usage of a reliable transport mode (similar to TCP) at the PPP/link layer.

1663 Reject No

0x0B Multi-link Procedure Obsolete. Reject No

0x0C Callback Indicate desire for disconnect after authentication followed by automatic callback from peer.

1570 Reject No

0x0D Connect time Obsolete. Reject No

0x0E Compound Frames Specify manner to encapsulate multiple PPP frames within single link-layer frame.

1570 Reject No

0x0F Nominal-Data Encapsulation

Obsolete. Reject No

0x11 Multilink – MRRU MP (PPP link aggregation).

1990 Reject No

0x12 Multilink – Short Sequence Number Header Format

MP related. 1990 Reject No

0x13 Multilink – Endpoint Discriminator

MP related. 1990 Reject No

0x14 Proprietary Proprietary use. Reject No

0x15 DCE Identifier Specify manner to distinguish certain communications devices from routers, etc.

19761963

Reject No


LCP Option





During the LCP phase of negotiation, the Ixia port makes available the following options to the user.

Maximum Receive Unit

This LCP parameter (actually the set of Maximum Receive Unit (MRU) and Maximum Transmit Unit (MTU)) determines the maximum allowed size of any frame sent across the link subsequent to LCP completion. To be fully standards-compliant, an implementation must not send a frame of length greater than its MTU + 4 bytes + CRC length. For instance, if the negotiated MTU for a port is 2000 and 32 bit CRC is in use, no frame larger than 2008 bytes should ever be sent out that port. Packets that are larger are expected to be fragmented before transmitting or to be dropped. The Ixia port's MTU will be the peer's MRU fol-lowing LCP negotiation. Strictly speaking, the receiving side can assume that frames received will not be greater than the MRU. In practice, however, an implementation should be capable of accepting larger frames. If a peer rejects this option altogether, the negotiated setting defaults to 1500. Regardless of the negotiated MRU, all implementations must be capable of accepting frames with an information field of at least 1500 bytes.

For the transmit direction portion of the negotiation, the peer will send the Ixia port its configuration request. The Ixia port will accept and acknowledge the peer's requested MRU as long as it is less than or equal to the specified user's desired transmit value (but greater than 26). For the receive direction portion of the negotiation, the Ixia port will send a configuration request based on the user’s desired value. Generally, the Ixia port will accept what the peer desires (if it acknowledges the request, then the user value is used, or if the peer sends a Con-figure-Nak with another value the Ixia port will use that value as long as it is valid). This approach is used to maximize the probability of successful negotia-tion.

0x16 Multilink-Plus Proc. MP related: Proprietary to Ascend.

1934 Reject No

0x17 Link Discriminator MP related: Specifies parameters for Bandwidth Allocation Control Protocol

2125 Reject No

0x18 LCP Authentication Option

Proposed method for performing authentication within LCP.

Reject No


LCP Option





Asynchronous Control Character Map

ACCM is only really pertinent to asynchronous links. On asynchronous lines, certain characters sent over the wire can have special meaning to one or more receiving entities. For instance, common implementations of the widely used XON/XOFF flow control protocol assign the ASCII DC3 character (0x13) to XOFF. On such a link, an embedded data byte that happens to have the value 0x13 would be misinterpreted by a receiver as an XOFF command, and cause suspension of reception. To avoid this problem, the 0x13 character embedded in the data could be sent via an “escape sequence” which consists of preceding the data character with a dedicated tag character and modifying the data character itself.

The Asynchronous Control Character Map (ACCM) LCP parameter allows inde-pendent designation of each character in the range 0x00 thru 0x1F as a control character. A control character is sent/received with a preceding “control-escape” character (0x7D). When the 0x7D is seen in the received data stream, the 0x7D is dropped and the next character is exclusive-or’d with 0x20 to get the original transmitted character. ACCM negotiation consists of exchanging masks between peers to reach an agreement as to which characters will be treated as special con-trol characters on transmission and reception. For example, sending a mask of 0xFFFFFFFF means all characters in the range 0x00 thru 0x1F will be sent with escape sequences; a mask of 0 means no special handling, so all characters are arbitrary data.

Packet over Sonet is an octet-synchronous medium. If the link is direct between POS peers, neither side should be generating control-escapes. (Exceptions to this are bytes 0x7D and 0x7E: the former is the special control escape character itself; the latter is the start/end frame marker. Escaping of these two characters is gener-ally handled directly by physical layer hardware). On links in which there is some kind of intermediate asynchronous media, it is required that whatever device performs the asynchronous to synchronous conversion must also take care of any special character handling, isolating this from any POS port. See RFC 1662, sections 4.1 and 6.

If ACCM negotiation is enabled, the Ixia port advertises an ACCM mask of 0 to its peer in its LCP configuration request. The Ixia port accept whatever the peer puts forth, but does not act on the results. Regardless of the final negotiated set-tings for receive and transmit ACCM, the Ixia port does not send escape control sequences nor does it expect to receive them. This is the nature of a synchronous PPP medium, such as POS.

Magic Number

A magic number is a 32-bit value, ideally numerically random, which is placed in certain PPP control packets. Magic numbers aid in detection of looped links. If a received PPP packet that includes a magic number matches a previously trans-mitted packet, including magic number, the link is probably looped.

IxExplorer and the Tcl/C++ APIs allow global enable/disable of magic number negotiation. If the “Use Magic Number” feature is enabled, the Ixia port will not request magic number of its peer and will reject the option if the peer requests it.



If the box is checked, we will attempt to negotiate magic number. The result of the bi-directional negotiation process is displayed in the fields for transmit and receive: an indication of whether magic number is enabled is written in the field for the corresponding direction.

NCP – Network Control Protocols

IPCP – Internet Protocol Control Protocol Options

The following table outlines the parameters associated with the Internet Protocol Control Protocol. IPCP includes three command types, which are assigned option numbers in the pertinent RFCs. Note that PPP parameters are typically indepen-dently negotiated for each direction on the link. The “Negotiate” column indi-cates how Ixia’s present implementation handles each option/parameter during the negotiation process. “Full” means that full, bi-directional negotiation support. “Reject” indicates that the option is not supported and a option rejection will be sent if the peer attempts to negotiate the option. A check in the “User Access” column means user control is provided for the option via IxExplorer or the Tcl/C++ APIs. Several RFCs are associated with IPCP. Notes on key parameters fol-low the table.

IP Address

The process of negotiation of IP addresses for the peers can be problematic. RFC 1332 does not devote enough detailed attention to the issue and other references tend to be conflicting. Behavior of equipment from different vendors can be expected to vary. For example, some equipment requires, by default, that a peer’s IP address be in the same IP subnet as their own; if not, negotiation may fail or may even become caught in an indefinite negotiation loop.

The sender of this Configure-Request may either include its own IP address, to provide this information to its remote peer, or may send all 0.0.0.0 as an IP address, which requests that the remote peer assign an IP address for the local node. The receiver may refuse the requested IP address and attempt to specify

Table 3-10.PPP - IPCP Options

LCP Option



0x01 IP Addresses (static)

Obsolete. Reject No

0x02 IP Compression Protocol

Specify protocol to use for compression of IP and TCP header. Only current options are none or VJ (Van Jacobson).

1332 Reject No

0x03 IP Address Provide means to specify own as well as peer’s IP address.

1332 Limited Yes



one for the peer to use by using a Configure-NAK response to the request with a specification of a different address.

The Ixia implementation provides minimal configuration of this parameter. The Ixia user must specify the local IP address of the unit and the peer must provide its own IP address. The Ixia port will accept any IP address the peer wishes to use as long as it is a valid address (e.g., not all 0's). The Ixia port expects the peer to accept our address. If, however, the peer specifies a different address for us to use we will acknowledge that address but not actually notify the user that this has happened. The Ixia port will accept a situation in which local and peer addresses are the same following negotiation.

OSINLCP - OSI Network Layer Control Protocol

A single option is provided for this NCP protocol. If a non-zero value for align-ment has been negotiated, subsequent ISO traffic (e.g., IS-IS) will arrive with or be sent with 1 to 3 zero pads inserted after the protocol header as per RFC 1377.

MPLSCP - MPLS Network Control Protocol

No options are currently available for this protocol setup.

Retry Parameters

During the process of negotiation, the port uses three Retry parameters. RFC 1661 specifies the interpretation for all of the parameters.Table 3-11.PPP Retry Parameters

Parameter Purpose Range Default

Configure-Request Set the maximum number of configure requests that the Ixia port will re-send without getting an ack, nak or reject before beginning a termination process. This setting is used for both LCP and IPCP. RFC 1661 refers to this parameter as “Max-Configure”.

2 - 255 9

Termination Request Set the maximum number of termination requests that the Ixia port will send without getting an ack before forcing the link down. RFC 1661 refers to this parameter as “Max-Terminate.”

2 - 255 3

Retry Time-out Set the retransmission time-out, in seconds, between consecutive retries. This applies to all transmission retries. RFC 1661 refers to this parameter as “Restart Timer.”

2 - 10 3



Chassis Synchronization

Measurement of unidirectional latency and jitter in the transmission of data from a transmit port to a receive port requires that the relationship between the time maintained at each of the ports is known. This is not required for measuring roundtrip properties since the same port sends and receives the data. This can be accomplished by providing one of the following signals between chassis:

• Clock (frequency standard): this allows chassis to phase-lock their fre-quency standards so that a cycle counter on any chassis will count the same number of cycles during the same time interval. Each Ixia port maintains such a counter from a common chassis-wide frequency standard.

• Reset: Phase-locking the frequency standards between chassis allows ports on different chassis to count the same number of cycles during a given time interval. However, this does not allow the transmission delay to be calculated. A means of either discovering the fixed offset between their counters or simultaneously setting the counters to a known value must exist. It is conceptually easy to think of this as the "zero reset".

In widely distributed applications, such as monitoring traffic characteristics over a WAN, these signals cannot be transmitted between chassis over a physical con-nection because of unknown delay characteristics. An alternative means is required to satisfy these requirements.

Ixia has provided facilities that allow for the synchronization of independent Ixia chassis located anywhere in the world by replacing the existing inter-chassis sync cables with a widely available frequency and time standard supplied from an external source. Accurate timing can be used to obtain accurate latency and other measurements in a live global network. When geographically dispersed chassis are connected in this way, the combination is called a ‘virtual chassis chain’.

Worldwide Synchronization

Two or more Ixia 100 chassis and/or IxClock modules may be distributed world-wide, forming a virtual chassis chain based on GPS and/or CDMA timing. One possible configuration is shown in Figure 3-21 on page 3-40.

Figure 3-21. Worldwide Deployment of Synchronized Chassis

The ports on all of the chassis may be shared by one or more Ixia software users located likewise anywhere in the world. Where GPS and CDMA sources are

SO

Ixia 1600

Ixia 100 IxClock

Ixia 400Ixia 1600SI

SOSI

SOSI

Ixia 100

NYC Paris Tokyo

Miami San Jose

IxExplorer ScriptMate

Chicago

TCL



used, all of the sources must have good quality time values in order to for the trigger to be transmitted.

Once the timing features of the chassis are configured, operating a worldwide set of Ixia chassis is the same as local operation. The Ixia hardware and software programs the clocks such that they all send a master trigger pulse to all Ixia chas-sis, within a tolerance of ±80 ns with GPS and ±100 us for CDMA.

Ixia chassis timing operates by setting a time-of-day from one source and then maintaining the time accuracy through a potentially different means. Table 3-12 on page 3-41 describes the full set of options available and their approximate rel-ative accuracies.

The specifications of the GPS unit are detailed in the Ixia Hardware Guide.

Three scenarios are discussed below:

• Independent Operation – each Ixia 400, 1600 or Optixia chassis chain gener-ates its own timing.

• Ixia 100 – a one-slot chassis which includes a GPS receiver.

• IxClock – a separate module which generates a timing signal from multiple sources.

Table 3-12.Summary of Timing Options

Available on Devices

Timing Option

Time of Day Accuracy

Frequency Source

Frequency Accuracy

Ixia 100, 400, 1600

Synchronous N/A Internal PC clock

1 microsecond / second

Ixia 100, 400, 1600

CDMA 100 microseconds from GMT

CDMA Stratum 1

Ixia 100, IxClock

GPS (with attached antenna)

150 nanoseconds from GMT

GPS Stratum 1

IxClock GPS (with T1/E1 or 1PPS input)

150 nanoseconds T1/E1 or 1PPS

Dependent on the accuracy of the selected frequency source

IxClock GPS (with no fixed input)

150 nanoseconds, degrading to 1 ms over 3 months

Internal rubidium oscillator

1 nanosecond / second



Independent Operation

Independent Ixia 400, 1600, or Optixia chassis may synchronize themselves with other chassis as shown in Figure 3-22 on page 3-42.The timing choices are explained in Table 3-13 on page 3-42.

Figure 3-22. Independent Chassis Timing

Ixia 100

If the two chassis are separated by any significant distance, a sync-out/sync-in cable cannot be used to connect them. In this case, two Ixia 100 chassis with built-in Global Positioning Satellite (GPS) or Code Division Multiple Access (CDMA) are attached to each chassis through sync-out/sync-in cables, as shown in Figure 3-23 on page 3-43. The Ixia 100s maintains an accuracy of less than

Other Time Source

Internal Sync

SO SI

Ixia 1600 Ixia 400

Table 3-13.Independent Chassis Timing Choices

Choice Usage

Internal Sync (Synchronous)

If a chassis is used in a stand-alone manner or the master of a chassis chain, it may generate its own start signal. In general, there is insufficient timing accuracy between timing masters for measurements over any distance. This is also known as synchronous timing.

Sync-In (SI) If a chassis is a slave, either directly connected to the master chassis or further down the chain, it will derive its timing from the previous chassis’ Sync-Out (SO) signal.

CDMA The CDMA cellular network transmits an accurate time signal.

Other Time Source (PC Clock)

A number of hardware / software products are available which provide accurate PC time sources. Any Windows 2000 compatible products may be used with the Ixia chassis. For example, see TRSync offered by Masterclock Inc. (http://www.masterclock.com/).



150 nanoseconds when attached to a GPS antenna or 100 microseconds when attached to a CDMA receiver and provide chassis to chassis synchronization.

Figure 3-23. Chassis Timing Using an Ixia 100

The Ixia 100 chassis contains one slot for an Ixia load module. The additional timing features available with the Ixia 100 are shown in Table 3-14 on page 3-43.

The Sync-Out from the Ixia 100 is used to master a chassis chain at a specific geographic location. Since the Ixia 100 chassis has all other functions provided by the other Ixia chassis, it may also use independent timing when not used to synchronize with other chassis at other locations.

IxClock

The final choice involves the use of an IxClock chassis. This is shown in Figure 3-24 on page 3-44.

Table 3-14.Ixia 100 Chassis Timing Choices

Choice Usage

GPS The Ixia 100 requires connection to an external GPS antenna in order to ‘capture’ multiple GPS satellites. It will maintain an accuracy of less than 150 nano-seconds

CDMA The CDMA cellular network transmits an accurate time signal. CDMA (Code Division Multiple Access) cellular base-stations effectively act as GPS repeaters. The Ixia 100-CDMA has a built-in CDMA receiver with a small antenna on the back on the chassis that receives the CDMA signals passively (you do not need to subscribe to any service) and decodes the embedded GPS signal. Using this approach, the Ixia 100 can be time-synched to GPS - with NO EXTERNAL ANTENNA ON THE ROOF.



Figure 3-24. IxClock Chassis Timing Choices

The IxClock module is a separate rack-mountable chassis for use in isolated envi-ronments where GPS or CDMA antenna placement is not possible. The IxClock includes provisions for multiple reference sources. At the heart of the IxClock chassis is a GPS unit. This GPS unit, with its battery pack, may be taken outside and attached to an included antenna in order to obtain an accurate time lock. Once a time value is obtained, the IxClock unit may be brought inside where it will maintain a better than 1 millisecond accuracy for up to 3 months. The clock accuracy is maintained by an optional application 1 rubidium oscillator. The IxClock may, of course, be permanently connected to the antenna to maintain a 150 nanosecond accuracy. The functions of the IxClock module are controlled via a serial link from the chassis chain master. The full set of timing choices available are shown in Table 3-15 on page 3-44.

Bit Error Rate Testing (BERT)

As opposed to all other types of testing performed by Ixia hardware and software, BERT tests operate at the physical layer, also referred to as OSI Layer 1. POS frames are constructed using specific pseudo-random patterns, with or without inserted errors. The receive circuitry locks on to the received pattern and checks for errors in those patterns.

Table 3-15.IxClock Chassis Timing Choices

Choice Usage

Standalone Timing is provided autonomously by the IxClock unit by virtue of a permanently connected GPS or a temporary GPS connection maintained by a rubidium oscillator.

E1/T1 Time of day is set by the GPS unit and the time base is maintained by a E1/T1 signal connected to an IxClock connector.

1PPS Time of day is set by the NTP or GPS unit and the time is maintained by a 1 pulse per second signal connected to the IxClock front serial I/O connector.



BERT is available on specific POS Ixia load modules. Refer to the Ixia Hard-ware Manual for a list of modules that support BERT.

All of the Ixia PoS modules support concatenated, as opposed to channelized, operation. Therefore, the type of BERT testing performed by Ixia hardware is referred to as channelized, framed BERT testing.

The patterns inserted within the PoS frames are based on the ITU-T 0151 specifi-cation. They consist of repeatable, pseudo-random data patterns of different bit-lengths which are designed to test error and jitter conditions. Other constant and user-defined patterns may also be applied. Furthermore, the user may control the addition of deliberate errors to be added to the data pattern. The inserted errors are limited to 32-bits in length and may be interspersed with non-errored patterns and repeated for a count. This is illustrated in Figure 3-25. In the figure, an error pattern of n bits occurs every m bits for a count of 4. This error is inserted at the beginning of each PoS data block within a frame.

Figure 3-25. BERT Inserted Error Pattern

Errors in received BERT traffic are visible through the measured statistics, which are based on readings at one-second intervals. The statistics related to BERT are shown in Table 3-16. Those statistics defined in ITU-T G.826 are indicated with a ‘*’.

PoS Data Block

Width = n bits (<= 32 bits)

Period = m bits (>= n bits)

Count = 4

Table 3-16.BERT Related Statistics

Statistic Usage

Status Indicates whether the receiving port, which is usually different than the transmitting port, is locked into the expected data pattern or not.

Bits Sent The number of bits transmitted on the port.

Bits Received The number of bits received on the port.

Bit Errors Sent The number of bits inserted into the transmitted stream.

Bit Errors Received

The number of bits received in error.

Errored Blocks* The number of blocks in which one or more bits are in error.

Errored Seconds* (ES)

The number of one-second periods with one or more errored blocks or at least one defect.



Available / Unavailable Seconds

Reception of POS signals can be divided into two types of periods, depending on the current state – Available or Unavailable, as shown in Figure 3-26. The sec-onds occurring during an unavailable period are termed Unavailable Seconds

Severely Errored Seconds* (SES)

The number of one-second periods which contain 30% errored blocks or at least one defect.

Error Free Seconds* (EFS)

The number of one-second periods for which no bit error or defect was detected.

Available Seconds* (AS)

The number of seconds for which the data transmission was available. See Available / Unavailable Seconds on page 3-46.

Unavailable Seconds* (UAS)

The number of seconds for which the data transmission was unavailable. See Available / Unavailable Seconds on page 3-46.

Block Error State Indicates whether the most recent block received is Available or Unavailable. See Available / Unavailable Seconds on page 3-46.

Background Block Errors*

The number of errored blocks not occurring as part of a Severely Errored Second.

Errored Second Ratio (ESR)*

This ratio results from the following calculation: Where P = the total measurement period (in seconds), and c = count:ESR = cES/(P-UAS)

Severely Errored Second Ratio (SESR)*

This ratio results from the following calculation: Where P = the total measurement period (in seconds), and c = count:SESR = cSES/(P-UAS)

Background Block Error Ratio (BBER)*

This ratio results from the following calculation: Where P = the total measurement period (in seconds), and c = count:BBER = cBBE/[(P-UAS-cSES) x 8000 blocks per second]

Table 3-16.BERT Related Statistics

Statistic Usage



(UAS); those occurring during an available period are termed Available Seconds (AS).

Figure 3-26. BERT- Unavailable/Available Periods

These periods are defined by the error condition of the data stream. When 10 consecutive SESs (A in the figure) are received, the receiving interface triggers an Unavailable Period. The period remains in the Unavailable state (B in the fig-ure), until a string of 10 consecutive non-SESs is received (D in the figure), and the beginning of the Available state is triggered. The string of consecutive non-SESs in C in the figure was less than 10 seconds, which was insufficient to trig-ger a change to the Available state.

A C

Error-free Second

Errored Second (non-SES)

Severely Errored Second (SES)

Unavailable period/Unavailable seconds (UASs) Available period/

Availableseconds(ASs)

Time

Availabilitydetected

Unavailability detected

0 5 10 15 20 25 30 35

B E

D


Theory of OperationIxia Software3

Ixia SoftwareDifferent software packages are available which utilize Ixia hardware. Individual manuals are available for each.

• IxExplorer – an interactive, GUI-based software interface which allows all features of the Ixia hardware to be programmed and operated. The program-ming paradigm calls for each port to be individually set up, and included facilities for copying port configuration from one port to others. A number of displays are available for viewing captured packets, statistics and port latency.

• ScriptMate – an interactive, GUI-based software interface which allows for the configuration of pre-programmed TCL tests. Tests are provided for stan-dard RFC requirements, quality of service and performance measurement. Specific tests are provided for specific technologies and protocols associated with Cable Modems, Load Balancing Servers, Wireless IP and Border Gate-way Protocol. The GUI controls which ports are used during testing as well as their configuration. It also enables modification of the basic parameters of the tests themselves. Logs are produced with test results.

• TCL – an API (application programming interface) which allows program-mers conversant with the TCL programming language to control all aspects of Ixia hardware operation. The ScriptMate provided programs utilize this API.

• C++ – an API which allows programmers conversant with the C++ program-ming language to control all aspects of Ixia hardware operation.

• IxTrafficTM - Fully distributed system for collecting, aggregating, and visu-alizing traffic metrics of backbone routers.

• IxCoreTM - Scalable, highly accurate system for one-way performance mon-itoring of latency, packet loss, and jitter, designed to be deployed in the core of the IP network. It is based on the IETF IPPM RFCs and features real-time reporting and notification mechanisms. Used to validate the network’s ability to carry the next generation converged services.

• IxEdgeTM - Highly scalable system for round-trip performance monitoring of latency, packet loss, path stability and availability, designed to monitor the edge of the IP network. It can simultaneously monitor thousands of paths to validate and enforce customer service level agreements (SLAs).

• IxProfileTM - High-speed passive monitoring system that reports key traffic profiles like protocol distributions and traffic size distributions. Designed for use by ISPs, network service providers, and carriers to characterize the traffic on their backbones and perform non-intrusive, real-time packet analysis with-out sampling or degrading router performance.

• IxMappingTM - Effectively identifies the geographic source and destination of routers, servers, and other network infrastructure elements. Used for secu-rity, authentication, and network management.


Theory of OperationTcl Software Structure

An additional tool, called Scriptgen, can be used to generate a TCL program that reflects the state of a single Ixia port. Scriptgen is written in TCL and uses the TCL API. The state of the port which is dumped by Scriptgen is most often set up using IxExplorer, but any means of setting up the port may precede Scriptgen usage. The Scriptgen generated program is entirely self-contained and execut-able; when executed it will re-establish the port’s state. With suitable modifica-tion, however, it could be included in a larger TCL program in order to construct a complete end-to-end test.

•

• SONET Headers

• PPP for use with SONET. Includes dialogs for Negotiation, Link Control Pro-tocols, and Network Control Protocols.

• SONET Overhead

Tcl Software StructureThe Tcl software is structured as a number of client-server pieces so that it may operate simultaneously in three different environments:

• On the Ixia chassis—the Tcl scripts are executed on the same computer that runs the Ixia hardware.

• On a Windows client—the Tcl scripts are executed on a Windows NT/95/98 client.

• On a Unix client—the Tcl scripts are executed on a Unix client.

The following sections describe the components used in each of these scenarios.


Theory of OperationTcl Software Structure3

Operation on the Ixia Chassis

When the Tcl client software is installed on the Ixia chassis itself three distinct software components are used, as shown in Figure 3-27.

Figure 3-27. Software Modules used on an Ixia Chassis

In this scenario, three components are used as described in Table 3-17.Table 3-17.Software Modules used on an Ixia Chassis

Module Usage

Tcl scripts Ixia supplied and user developed Tcl. The Tcl extensions that program the Ixia hardware use the TclHAL layer.

TclHAL A layer of software, supplied as a DLL (Dynamic Linked Library), that is responsible for interpreting the Tcl commands into C++ functions to be sent to the IxServer software.

IxServer An independent Windows executable that is responsible for directly controlling the Ixia hardware.

Ixia Chassis

IxServer

Tcl script

Tcl script

TclHAL



Operation on a Windows Client

When the Tcl client software runs on a Windows client, the same three compo-nents are used but in a different configuration, as shown in Figure 3-28.

Figure 3-28. Software Modules used on a Windows Client

In this scenario, three components are used as described in Table 3-18.Table 3-18.Software Modules used on a Windows Client

Module Usage

Tcl scripts Ixia supplied and user developed tests run on the Windows client using the Tcl software. The Tcl extensions that program the Ixia hardware use the TclHAL layer.

TclHAL A layer of software, supplied as a DLL (Dynamic Linked Library), that is responsible for interpreting the Tcl commands into C++ functions to be sent to the IxServer over the local network.

IxServer An independent Windows executable running on the Ixia Chassis that is responsible for directly controlling the Ixia hardware. Its commands are received from clients over the LAN.

Ixia Chassis

IxServer

Windows Client

Tcl script

Tcl script

TclHAL

Network



Operation on a Unix Client

When the Tcl client software runs on a Unix client, five components are used as shown in Figure 3-29.

Figure 3-29. Software Modules used on a Unix Client

In this scenario, five components are used as described in Figure 3-29.Table 3-19.Software Modules used on a Unix Client

Module Usage

Tcl scripts Ixia supplied and user developed tests run on the Windows client using the Tcl software. The Tcl extensions that program the Ixia hardware use the Tcl-DP client software.

Network Interface This is a layer of software within the TCL system that translates hardware commands into ascii commands, which are sent to the TCL Server on the connected Ixia chassis.

TclServer Receives commands from the Tcl-DP client on Unix client platforms. Commands are translated into calls to the TclHAL layer.

TclHAL A layer of software, supplied as a DLL (Dynamic Linked Library), that is responsible for interpreting the Tcl commands into C++ functions to be sent to IxServer on the chassis over the network.

IxServer An independent Windows executable running on the Ixia Chassis that is responsible for directly controlling the Ixia hardware. Its commands are received from clients over the LAN.

Unix Client

Tcl script

Tcl script

Network Interface

Network

Ixia Chassis

IxServer

TclServer

TclHAL



Multiple Client Environment

A single Ixia chassis may be used by multiple clients simultaneously. Clients may run from the Ixia chassis, Windows clients, and Unix clients simultaneously, as shown in Figure 3-30.

Figure 3-30. Multi-Client Environment

Ixia Chassis

IxServer

Tcl script

TclHAL TclServer

Unix Clients

Tcl script

Network IF

Tcl script

Network IF

Tcl script

Windows Clients

Tcl script

TclHAL

Tcl script

TclHAL


4API Structure and ConventionsThis chapter discusses general structure of the Ixia Tcl commands and suggested programming sequence.

Most of the Tcl commands have the same basic structure:

• A number of configuration options that are used to set test and other parame-ters.

• A standard set of options that push the data options toward the hardware and read information back from the hardware.

• Additional command specific options used to perform special settings or operations.

Standard Sub-Commands

The standard sub-commands that come with most commands are:

Chapter 4: Programming

TABLE 4-1. Standard Options

Method Usage

config Sets a specified value to a specific option, which is most often a desired hardware setting. The value is stored in an object in IxTclHAL temporarily.

cget Gets a specified option’s value, which was stored in the IxTclHAL object.

set Information is transferred from the IxTclHAL object to the IxHal software layer, but not sent to the hardware. The set method takes as arguments the chassis ID, card number and port number being addressed.


ProgrammingAPI Structure and Conventions4

In general hardware parameters may be saved through the use of a ‘config’ option and then retrieved at any later time via a ‘get’ option followed by a ‘cget’ option. This is because the IxHal level maintains memory of all of the settings. This relationship of methods is illustrated in Table 4-1 on page 4-1.

Note that a single instance of each command exists, with a set of associated data variables, called standard options. The standard options from one command are often used in another. For example, the ipAddressTable command uses the standard options from the ipAddressTableItem command. The most recent standard options from the ipAddressTableItem command are used by the ipAddressTable command. Make sure that the standard options from depen-dent commands are set immediately before being used. Intervening commands may interfere.

The values defined in the tables for each of the API commands may be used in several ways:

• As an argument to a config command. For example, both:

port config -masterSlave portMaster -and-port config -masterSlave $::portMaster

are valid. In the first case, the port config command figures out the value of portMaster (0). In the second case, the global variable $::portMaster (which is defined in the IxTclHal package) is used to determine a value of 0. The :: qualifier indicates that the variable is defined in the global context.

• As a variable used for comparison. For example:

port get 1 1 1set msValue [port cget -masterSlave]if [$msValue == $::portMaster] ...

Here the $:: form must be used to refer to the value of portMaster.

write Information previously transferred to the IxHal software layer is sent to the hardware.The write method takes as arguments the chassis ID, card number and port number being addressed. Although each class provides its own write method, it is usually more convenient to call ixWriteConfigToHardware, which will send all outstanding set’s to the hardware at the same time.

get Information from the hardware is read out to the IxHal layer and into the member variables. In many cases, the IxHal layer holds more information than is represented in a single set of member variables and additional methods are needed to obtain more data. The get method takes as arguments the chassis ID, card number and port number being addressed.

setDefault Default values for the members are set.

decode A captured frame is analyzed and appropriate member variables are set to reflect the contents of the frame.

TABLE 4-1. Standard Options

Method Usage


ProgrammingAPI Structure and Conventions

Figure 4-31. Standard Method Relationships

Tcl App

Tcl Cmnd

IxTclHal

IxHal

IxServer

set

write

get

cget config

Lib


ProgrammingSequence of Steps4

Sequence of StepsThe following sequence of steps should be followed to write a successful Tcl script:

1. Load the IxTclHal package.

The IxTclHal package contains all the Ixia Tcl Library commands. After load-ing this package, these commands are made available in the test script. The format of using the package command is as follows:

package require IxTclHal

2. Connect to the chassis on which the test is to be executed.

After loading the package, the chassis has to be connected to where the test is going to be executed. The following commands are used to connect and set up the chassis parameters:chassis add <hostname or IP address>chassis config -id <chassisID>chassis set <hostname or IP address>

The chassis add command connects to the chassis. The chassis config -id command associates a numeric ID with the chassis. The chassis set command sets the ID of the chassis in IxHAL. It is important to assign a chassisID to the chassis as it is used in the map command. If multiple chassis are to be used, then multiple chassis add commands must be given and each chassis should be assigned a unique ID.Alternatively, the following sequence could be used:ixInitialize <hostname or IP address>set chassisID [ixGetChassisID <hostname or IP address>]

The ixInitialize takes care of all three steps in the previous example, assigning a chassis ID on its own. The call to ixGetChassisID is needed to retrieve the assigned chassis ID for future use.

3. Set up the traffic mapping

This is an optional step. The mechanism for setting up traffic mapping is pro-vided only for convenience. Users may use their own methods for storing this information.Before any test can be executed, it is important to specify the flow of traffic, that is, the transmit and receive ports. The mapping for these ports is specified using the map command as follows:map config –type one2one; # or one2many, many2one, many2manymap add <TxChassisID> <TxCardID> <TxPortID> <RxChassisID> <RxCardID> <RxPortID>

This command will store the transmit chassis, card, port and receive chassis, card, port combinations in a Tcl array within the scope of the Tcl script. There are four types of mappings:

a: One to One mapping

b: One to Many mapping

c: Many to One mapping


ProgrammingSequence of Steps

d: Many to Many mapping

For the mappings specified in a), b), c), and d) above, the chassis, card, port combinations are stored in Tcl arrays one2oneArray, one2manyArray, many2oneArray and many2manyArray, respectively.Each Transmit/Receive combination in one2oneArray is unique. That is, there is only one Receive port for each Transmit port. The Receive port may also be set as Transmit port. Similarly, for the one2manyArray, any Transmit port cannot be used as a Receive port for a different set, and for the many2oneArray, any Receive port cannot be used in a different set of the many-to-one map. The many2manyArray can contain any combination of transmit and receive ports. A port can be assigned to be a Receive port for any number of Transmit ports and can also act as a Transmit port for several Receive ports.

The map command is very useful when writing scripts. Upon closer inspec-tion, it will be apparent that the Transmit ports in the traffic flow are all stored as elements of the arrays (except for many2oneArray) and the Receive ports are stored as values (Tcl Lists) of these arrays. This method of storage allows a great deal of flexibility when this information is needed. In Tcl, the com-mand [array names one2oneArray], for example, will give access to all the Transmit ports and to access the Receive port, $one2oneArray($txChas-sis,$txCard,$txPort) gives the list with the Receive chassis, card, port combi-nation.

4. Set up test related parameters

The test related information such as duration of test, number of trials, config-uration of learn frames and IP/IPX addresses may be set up next.

5. Configure the port parameters

The port parameters such as speed, duplex, loopback and auto-negotiation must be set in IxHAL and then in hardware (by sending the message to IxServer). The following steps should be followed to configure the ports:port config -autonegotiate trueport config -duplex full

TABLE 4-2. Traffic Map Array

Array Type Format

one2oneArray one2oneArray(txChassis,txCard,txPort) {{rxChassis rxCard rxPort}}

one2manyArray one2manyArray(txChassis,txCard,txPort) {{rxChassis1 rxCard1 rxPort1}{rxChassis2 rxCard2 rxPort2} ………… {rxChassisN rxCardN rxPortN}}

many2oneArray many2oneArray(rxChassis,rxCard,rxPort) {{txChassis1 txCard1 txPort1}{txChassis2 txCard2 txPort2} ………. {txChassisN txCardN txPortN}}

many2manyArray many2manyArray(txChassis,txCard,txPort) {{rxChassis1 rxCard1 rxPort1}{rxChassis2 rxCard2 rxPort2} ……. {rxChassisN rxCardN rxPortN}}



port config -numAddresses 1port config -MacAddress {00 01 02 03 04 05}port set $chassisID $cardID $portIDport write $chassisID $cardID $portID

The addresses for the ports are assigned in this step. Note that for the Tcl scripts, the addresses are assigned to ports but they are actually configured in the streams (see step 6). This is due to the fact that when executing tests that send and receive traffic from switches and routers, addresses are assigned to physical ports. The concept of streams is invisible to the switches and routers. The MAC address is assigned to the port using the port config -MacAddress command. The source and destination IP addresses are assigned to ports using the ip command. Similarly, the IPX network and node addresses and sockets are assigned to ports using the ipx command. The following is an example showing the assignment of IP addresses to a port:ip config -sourceIpAddr 198.18.1.100ip config -destDutIpAddr 198.18.1.1ip config -destClass classCip config -sourceClass classCip set $chassisID $cardID $portID

6. Configure the streams on the transmit ports

The traffic is sent in streams, which contain the frame characteristics. Multi-ple streams may be created per port. The important parameters in the stream are frame size, inter-frame gap, frame data type, the number of frames to be transmitted, the source and destination MAC addresses in each frame and whether they are incrementing, decrementing or fixed. When configuring the protocol related parameters such as MAC, IP or IPX addresses, the protocol configuration will not be written to hardware until a stream set command is used. In addition, the User Defined Fields (UDFs) can be configured to over-lay a 1 to 4 byte custom pattern over the specified frame data. Examples of usage for UDFs include setting up filters on the receive ports for a particular UDF pattern, allowing an incrementing IP address or IPX socket, and adding a sequence ID to the frame.The following few lines show some stream configurations:stream config -numFrames 10000stream config -name "MyStream"stream config -dma stopStream

# Calculate the inter-frame gap using the utility command, calculateGapstream config -ifg [calculateGap $rate $framesize $preambleSize $speed]

# get the transmit chassis, card, port combination from the Tcl# array created by the map command by using [array names <mapArray>].# For example, the txChassis,txCard,txPort combination for the first# set in the one2oneArray can be obtained as follows:# set txMap [lindex [array names one2oneArray] 0]# scan $txMap "%d %d %d" txChassis txCard txPortport get $txChassis $txCard $txPortset txPortMacAddress [port cget -MacAddress]



# The source MAC address of the port is set in the streamstream config -sa $txPortMacAddress

# The destination MAC address of this transmit port can be obtained# from the receive port by using:# set rxMap $<mapArray> ($txChassis $txCard $txPort)# scan rxMap "%d %d %d" rxChassis rxCard rxPortport get $rxChassis $rxCard $rxPortstream config -da [port cget -MacAddress]

# overwrite 4 bytes of the frame data at offset 42 with magic# pattern "BE EF" using UDF 4udf config -offset 42udf config -enable trueudf config -countertype c8x8udf config -initval "BE EF"udf set 4

# set the current stream configuration in IxHAL as the first stream# on this portstream set $txChassis $txCard $txPort 1

7. Configure the filters parameters on receive ports

The filters are used to count or capture desired format of frames. To capture the frames, the capture trigger and capture filter parameters have to be enabled. Two counters, User Defined Statistics Counter 1 and User Defined Statistics Counter 2, can be enabled to count frames that match the defined constraints. The UDF values that are set using the stream command can be fil-tered upon and counted using these counters. To define the constraints on these counters, the filterPallette command can be used to specify up to two Destination MAC addresses, two Source MAC addresses and up to two pat-terns.# Enable the User Defined Statistics Counter 1, Capture# trigger and capture filter countersfilter config -userDefinedStat1Enable truefilter config -captureFilterEnable truefilter config -captureTriggerEnable true

# set the User Defined Statistics Counter 1 to count frames# that have destination MAC address "00 01 02 03 04 05"filter config -userDefinedStat1DA "00 01 02 03 04 05"

# set the capture filter counter to capture frames# that have pattern "BE EF"filter config - captureFilterPattern "BE EF"

# set up the filter pallettefilterPallette config -DA1 "00 01 02 03 04 05"filterPallette config -pattern1 "BE EF"filterPallette config -patternOffset1 42

# obtain the receive chassis, card, port combination and set the# filter and filter pallette on the receive portfilter set $rxChassis $rxCard $rxPort



filterPallette set $rxChassis $rxCard $rxPort

8. Write the configuration into hardware

After the stream and filter configurations are set in IxHAL, a message must be sent to IxServer to commit these configurations to hardware. Every com-mand has a write sub-command that writes that command related information into the hardware. However, it is inefficient to commit to hardware after updating every parameter as it might effect the performance of system. A more efficient method of writing to hardware is to update all the IxHAL objects first and send out one message to IxServer. For example, after all the chassis, ports, filters and stream information is set up in IxHAL, a message can be sent to the IxServer requesting it to write every configuration on a chassis.There are two recommended methods of writing to hardware:

a: If a traffic map was set-up in step (3):

ixWriteConfigToHardware <map>

Here the <map> is one of one2oneArray, one2manyArray, many2oneArray or many2manyArray.

b: If a traffic map was not set-up in step (3):

set portlist {{1 1 1} {1 1 2} {1 1 3} {1 1 4}}ixWriteConfigToHardware portlist

The portlist variable is a list of lists, each member containing three ele-ments: chassis, card and port.

Note that ixWriteConfigToHardware does not send port configuration changes (e.g. mii settings, port speed or auto-negotiation) to the hardware. If changes have been made to these parameters, use ixWritePortsToHardware. Note, however that this may result in a loss of link, depending on the changes that have been made.

9. Start the transmission

Now that the configuration is set in hardware, transmission of the streams on all the involved ports is started. A utility command startTx is provided that will start the transmission on all the ports simultaneously. StartTx command is called with the array created by the map command (one2oneArray, one2manyArray, many2oneArray, or many2manyArray) as an argument. This command uses the portGroup command to add all the Transmit ports in the array to a group with a given ID. This group ID is then used to send a message to the IxServer to start transmission at the same time.

10. Validate the received frames on receive ports

Usually, only frames that were transmitted must be counted to obtain reason-able results. The DUT may be transmitting management frames periodically, which should not be counted in the validating scheme of the test. As dis-cussed earlier, the UDFs and filters are used in streams to achieve this. The statistics counters such as the User Defined Statistics Counters are used to count the valid frames and calculations may be performed to get desired results. Frames may also be captured that may be decoded and counted.

11. Output results



Finally, the results may be obtained from the statistics or frames captured in the capture buffer and stored in any desired format.


ProgrammingHow to write efficient scripts4

How to write efficient scriptsA script is a logical sequence of operations that are sequentially executed. How-ever, a script is an application program that must be designed carefully just like a normal C or C++ program. Because a Tcl script does not need to be compiled as in a C/C++ code, it is actually more difficult to get the best optimized code for a Tcl script.

Also, compared to a GUI application where events take place very slowly (click-ing on buttons using a mouse), a script will pass through the same events very quickly. This speed of execution may cause time synchronization problems with the IxServer application on the chassis. Therefore, it is very important to imple-ment the sequence of events in a very intelligent way so as to achieve the most optimized execution of these events.

Before writing any script, it helps to first design the logic of the test using flow-charts or similar methods. More importantly, the logic should first be imple-mented in the IxExplorer GUI application to test the algorithm of the script. Therefore, it is of paramount importance that the user understand the concepts of streams, filters, UDFs, capture buffers, and so on before writing any script. These are described in Theory of Operation.

It is important to follow the sequence of steps outlined in “Sequence of Steps” on page 4-4. Here are the reasons:

1. It is important to configure the Port Properties in the very beginning of the script. For example, on a 10/100 card, there is an autonegotiation parameter. If this parameter is to be turned on, then during the auto-negotiation process, the link goes down and it takes a small amount of time to come up again. If there are a number of ports involved, the setting of port properties can take a long time. Therefore, it is always recommended that the ports be set first. This is done using the port set and port write commands. Do not implement this step in the middle of the script since it will only slow down the total time of execution of the test.

2. To send and receive traffic on the ports, the transmit and receive port map-pings must be defined and the port numbers stored in a structured array or list. This way, when streams and filters are to be configured, this array or list only needs to be looped through.

3. Before creating streams on the transmit ports, decide how many streams are needed to achieve the traffic profile to be used. It is possible that only one stream is needed in most cases. If not certain, use the IxExplorer GUI applica-tion to create the stream and transmit frames on it. Try to avoid creating streams for every iteration of the test. Sometimes it is easier to create all the necessary streams and simply disable the unneeded ones during the iterations.

4. To verify the filters, use the IxExplorer GUI to first mimic the situation. Use magic numbers in the payload of the frames wherever possible so that only the frames involved in the test are received. The magic numbers eliminate the inclusion of loopback, management frames or Spanning Tree BPDUs, for example, forwarded by the DUT.


ProgrammingMulti-Client Usage

5. If your script is running in a small loop and requesting data very quickly from IxServer, it is possible IxServer will not be able to keep up with the requests. If your script must request statistics or other data in a small for or while loop, consider using delays using the Tcl after command.

Multi-Client UsageIt is occasionally helpful to run IxExplorer at the same time as the Tcl Develop-ment environment. IxExplorer can provide instant visual verification. When doing so, it is important to perform a Chassis Refresh operation in IxExplorer after executing several important Tcl setup commands:

• ixSetCaptureMode

• ixSetPacketFlowMode

• ixSetPacketGroupMode

• ixSetPacketStreamMode

• ixSetPortCaptureMode

• ixSetPortPacketFlowMode

• ixSetPortPacketGroupMode

• ixSetPortPacketStreamMode

• ixWriteConfigToHardware

• ixWritePortsToHardware

Mpexpr versus ExprStatistics and other values used in the Ixia Tcl environment are 64-bit as opposed to 32-bit values. It is important to use mpexpr, as opposed to expr, in order to cal-culate expressions and maintain 64-bit accuracy. The 64-bit values are indicated in the individual descriptive pages for the following commands:

• captureBuffer

• packetGroupStats

• portGroup

• stat


ProgrammingMpexpr versus Expr4


5This chapter presents an organized description of the IxTclHAL API commands based on major topics. The major topics covered are:

• Chassis, Cards and Ports—basic overhead to set up the test and the hard-ware.

• Data Transmission—setting up streams and flows to be applied to ports.

• Data Capture and Statistics—setting up conditions to capture received data and statistics.

• Protocol Server—special treatment given to IP, ARP, IGMP, BGP4, OSPF, IS-IS, RSVP and RIP.

All of the commands are covered within these sections, but only the most signifi-cant options and sub-commands are discussed. Not all of the options, nor all of the Sub-Commands can be assumed to be discussed in this chapter. In particular, if not otherwise noted the get, cget, config, set, setDefault, decode and write Sub-Commands are assumed to exist and to perform stan-dard functions.

Appendix A - IxTclHAL Commands includes complete descriptions of each of the Ixhal commands.

Chapter 5: IxTclHal API Description


IxTclHal API DescriptionChassis, Cards and Ports5

Chassis, Cards and PortsThese commands included in this section are related to the setup of tests, before any data is applied. As discussed in “Chassis Chain” on page 3-1, Ixia equip-ment is organized as a chain of individual chassis connected by Sync-In/Sync-Out wires (each of which must be multiples of 3 feet). The chassisChain com-mand is used to hold information about the chain as a whole. One copy should be instantiated for the lifetime of the program. The chassis command is used to define and add chassis to the chain. Each chassis has two very important options: id, which is referenced elsewhere in referring to all levels of hardware and name, which is the IP hostname/address used to communicate with the hardware. chassisChain sub-command broadcastTopology should be called after all chassis have been added to the chain. Although each individual chassis, card and port has an individual write method, ixWriteConfigToHardware is a conve-nient means of writing to all chassis, in synchronization.

With the advent of the IXIA 100, the means by which geographically distributed chassis chains may be synchronized has been expanded. This is controlled by the timeServer command.

Cards reside within chassis and the card command is provided to access several read-only version variables for the card.

Ports are the principal focus of setup programming in the Tcl API. All of the port’s characteristics are visible and changeable through port and its associated commands.

session session is an optional command used to control sharing of ports on one or more chassis. It should be used where there is any possibility of multiple users sharing chassis. session -login is used to log-in and portGroup -setCommand is used to take ownership of ports. See “session” on page A-252 for full details.

The important options and sub-commands of this command are:

version version provides access to assorted pieces of version information for the IxT-clHAL.dll module. Note that on Unix systems, a connection to the chassis must have occurred before version information is available. See “version” on page A-312 for full details and “ixInitialize” on page C-36 for connection information.

TABLE 5-20. session Options

Member Usage

userName The user’s name after login.

TABLE 5-21. session Sub-Commands

Member Usage

login Logs a user in for purposes of ownership.

logout Logs out the current user.


IxTclHal API DescriptionChassis, Cards and Ports

chassisChain A single instance of this command should be instantiated and not destroyed for the entirety of the test process. It is the container that holds all of the individual chassis designations and their connections. See “chassisChain” on page A-62 for full details.


timeServer The timeServer command handles the means by which chassis chains are coor-dinated. Refer to “timeServer” on page A-299 for details. A chassis chain may use any of four time sources:

• Internal–internally generated by the chassis.

• GPS Server–generated by the GPS within an IXIA 100 chassis or IxClock module.

• SNTP Server–generated by a network available SNTP (Simple Net-work Time Protocol) server.

• PC Clock–generated by the PC associated with the chassis.

• CDMA Server–generated by the CDMA unit within an IXIA 100 chassis or IxClock module.

The important options and sub-commands of this class are:

TABLE 5-22. chassisChain Options

Member Usage

startTime The delay time before port transmit starts.

TABLE 5-23. chassisChain Sub-Commands

Member Usage

broadcastTopology Must be called after the last chassis has been added with chassis.add.

TABLE 5-24. timeServer Command Options

Member Usage

timeSource The choice of time source.

sntpClient For the SNTP choice, the location of the SNTP server.

antennaStatus For the GPS unit, the antenna’s connection status.

gpsStatus For the GPS unit, the locked/unlocked status of the GPS.

gpsTime For the GPS unit, the GPS read time, in seconds.

pllStatus For the GPS unit, the status of the phased locked loop that is driven by the GPS.

qualityStatus For the GPS unit, the quality of the received GPS signal.

state For the GPS unit, the current state of the GPS.



chassis chassis is used in the definition of a chassis and addition of the chassis to the chassis chain. See “chassis” on page A-57 for full details.


card The card command retrieves several card characteristics. Refer to “card” on page A-53 for full details. The important options are:

port The port command controls the basic aspects of port setup. Some port and proto-col specific attributes are included in this command, while other aspects are cov-ered by additional commands in this section. Specifically, the following port types have the indicated additional commands that may be used to control addi-tional port features:

• 10/100 and 10GE XAUI/XGMII Mii – mii

• Universal Serial Bus – USB

• Packet over Sonet (POS) – sonet, ppp and pppStatus, hdlc, frameRelay

• POS/BERT (Bit Error Rate Testing) – bert and bertErrorGeneration

Note that the elements options DestMacAddress, MacAddress and numAddresses are stored as convenience for use by other sub-commands. Do

TABLE 5-25. chassis Options

Member Usage

id The identification number given to the chassis. This is used in most commands to associate with ports.

name This is the IP hostname or IP address of the chassis, which is used to actually communicate with the chassis. Use ‘localhost’ if you are running your Tcl application on the chassis itself.

sequence The sequence of a chassis in a chain.

TABLE 5-26. chassis Sub-Commands

Member Usage

add Adds a new chassis to the chain.

writeAll May be used to write all changes to the hardware for all ports on the chassis.

TABLE 5-27. card Options

Member Usage

fpgaVersion The FPGA version on the card.

hwVersion The card’s hardware version.

portCount The number of ports on the card.

type The type of the card.



not destroy the port instance until you are completely done with the port. See “port” on page A-185 for full details.

The important options and sub-commands of this command are:TABLE 5-28. port Options

Category Member Usage

Basic name The name associated with the port.

owner The name of the owner of the port.

type (Read-only) The type of the Ixia port. Both speeds and interface types are described.

loopback Controls whether the port is in loopback mode or not.

flowControl Enables flow control on the port.

linkState (Read-only) The current state of the link with the DUT.

Transmit transmitMode Controls the basic transmission mode of the port: • Packet stream • Packet flow• TCP Round Trip• Advanced Scheduler• Bit Error Rate Testing (BERT)

Receive receiveMode Controls the basic receive mode of the port:• Capture• PacketGroup• TCP Round Trips• Data Integrity• First Time Stamp• Sequence Checking• Bit Error Rate Testing (BERT)

Addressing DestMacAddress The destination MAC address. Note that port holds this and the next two values as a convenience only for use in other commands. Do not destroy the port instance until you are done using the port.

MacAddress The first source MAC address.

numAddresses The number of source addresses assigned to the port.

Flows usePacketFlowImageFile Controls whether the port is used in stream mode or flow mode. If set to flow mode, then the packetFlowFileName member should be set.



packetFlowFileName The name of the file containing the packet flow information.

Pause Control directedAddress The address the port will listen to for a directed pause message.

multicastPauseAddress The address the port will listen to for a multicast pause message.

For:10/100 Ports

autonegotiate Sets auto-negotiate mode for the port.

duplex Controls half / full duplex mode for the port.

advertise100FullDuplexadvertise100HalfDuplexadvertise10FullDuplexadvertise10HalflDuplex

These four elements control what speeds and duplex are advertised during autonegotiation.

speed 10 or 100 Mbps.

For:Gigabit Ports

rxTxMode Basic mode for the port:• Normal• Loopback• Simulate cable disconnect

advertise1000FullDuplex Controls whether gigabit full duplex will be advertised during auto negotiation.

advertiseAbilities Sets the type elements advertised during negotiation:• None• Send only• Send and Receive• Send and/or Receive

ignoreLink Causes the port to ignore the link.

negotiateMasterSlave Indicates whether master/slave mode should be negotiated.

masterSlave If master/slave mode is being negotiated, then this is the indicates the ports desire (master or slave). Otherwise this is the value associated with the link.

timeoutEnable Enables autonegotiation timeout.

For:Ethernet/USB

portMode Sets the port to Ethernet or USB mode.

TABLE 5-28. port Options




mii

The mii command is available for 10/100 MII and 10GE XAUI/XGMII ports only. Four commands are included in this set:

• mii–Reads and writes values to ‘old-style’ MII PHYs defined in IEEE 802.3. One internal and two external MII PHYs may be managed, mixed with MII AE PHYs.

• miiae–Defines, reads and writes to ‘new-style’ MII AE PHYs defined in IEEE 802.3ae. One internal and two external MII AE PHYs may be managed, mixed with MII PHYs. Each MII AE PHY may consist of 32 MMDs (MDIO Manageable Devices), each with up to 64k devices. The MMDs are defined and managed with the mmd command and the registers within those devices are managed by the mmdRegister command.

• mmd–Defines, reads and writes the devices associated with MII AE PHYs.

• mmdRegister–Sets the parameters associated with MMD registers.

For:POS Ports

rxCrc Indicates whether a 16 or 32 bit CRC is to be used on the receive side of the port.

txCrc Indicates whether a 16 or 32 bit CRC is to be used on the transmit side of the port.

TABLE 5-29. port Sub-Commands

Member Usage

getInterface Gets the interface type of the port:• 10/100• Gigabit• Packet Over Sonet

isValidFeature Determines if a port feature is available for the port

isActiveFeature Determines whether a port is currently configured correctly to use a feature

reset Removes all of the streams on a port.

setDefault Sets the port to default values.

setParam Operates as in config, but sets a single option.

TABLE 5-28. port Options




mii

See “mii” on page A-142 for full details. The important options and sub-com-mands of this command are:

miiae

See “miiae” on page A-146 for full details. The important options and sub-com-mands of this command are:

TABLE 5-30. mii Options

Member Usage

enableManualAutoNegotiate

If set, causes the port to auto-negotiate when the MII registers are written

miiRegister The MII register number to read/write.

phyAddress Physical address of the MII register location. -1 for the default.

readWrite The read/write properties of the register:• Disabled• Read-Only• Read-Write

registerValue The value of the selected register.

TABLE 5-31. mii Sub-Commands

Member Usage

get This method should be called first, before any cget operations. The register number indicated in miiRegister is read into readWrite and registerValue.

selectRegister After get is used, this method allows a different register (as indexed by miiRegister) to be made available in readWrite and registerValue.

set Sets the values from readWrite and registerValue to be written to the MII register indexed by miiRegister.

write Sends all modified MII registers to the hardware.

TABLE 5-32. miiae Options

Member Usage

phyAddress Physical address of the MII register location..

TABLE 5-33. miiae Sub-Commands

Member Usage

clearAllDevices Removes all associated devices from the MII.

addDevice Adds a device defined in the mmd command to the MII.



mmd

See “mmd” on page A-149 for full details. The important options and sub-com-mands of this command are:

mmdRegister

See “mmdRegister” on page A-150 for full details. The important options of this command are:

delDevice Removes a single MMD from the MII.

getDevice Retrieves the information about a single MMD in the MII. The data about the device is available through the use of the mmd and mmdRegister commands.

set Sets the devices associated with one of the three supported PHYs: Internal, External1 or External2.

get Gets the devices associated with one of the three supported PHYs: Internal, External1 or External2.

TABLE 5-34. mmd Options

Member Usage

address Address of the MMD device within its associated MII.

name Arbitrary name of the MMD device.

TABLE 5-35. mmd Sub-Commands

Member Usage

clearAllRegisters Removes all associated registers from the MMD device.

addRegister Adds a register defined in the mmdRegister command to the MMD.

delRegister Removes a single register from the MMD.

getRegister Retrieves the information about a single register in the MMD. This must have been preceded by an miiae getRegister command. The data about the device is available through the use of the mmdRegister command.

TABLE 5-36. mmdRegister Options

Member Usage

address Address of the register location.

name Arbitrary name of the register.

TABLE 5-33. miiae Sub-Commands

Member Usage



USB

See “usb” on page A-310 for full details.


Packet over Sonet

The next six commands allow for the setting of all PoS specific values. If the default values associated with a task are correct, then the corresponding com-mand need not be used.

sonet

See “sonet” on page A-254 for full details.

readWrite The read/write properties of the register:• Disabled• Read-Only• Read-Write

registerValue The value of the selected register.

TABLE 5-37. usb Options

Member Usage

deviceClassmanufacturerproductproductIDreleaseNumberserialNumbervendorID

Read-only characteristics of the device connected to the USB port, automatically read back from the port itself.

cpeMacAddress The MAC address of the device connected to the USB port.

ethernetMaxSegmentSizemaxUSBPacketSize

Describes packet constraints in working with the port.

TABLE 5-38. usb Sub-Commands

Member Usage

reset Sends a reset to the DUT, and causes the device options to be updated.

TABLE 5-36. mmdRegister Options

Member Usage



The important options of this command are:

sonetError

This command allows the parameters associated with a variety of simulated SONET errors to be programmed. The errors that are programmed may be inserted once, periodically or continuously. See “sonetError” on page A-258 for full details.

TABLE 5-39. sonet Options


Header header Sets the type of PoS header:• HDLC ppp—further settings can be

made through the use of hdlc, ppp and pppStatus commands.

• Cisco HDLC—further settings can be made through the use of the hdlc, ppp and pppStatus commands.

Interface interfaceType Sets the type and speed of the sonet interface:• OC3, OC12 or OC48.• STM1c, STM4c or STM16c.

Transmit dataScrambling Controls data scrambling in the sonet framer.

lineScrambling Controls line scrambling in the sonet framer.

CRC rxCrc Sets the receive CRC mode: 16 or 32 bit mode.

txCrc Sets the transmit CRC mode: 16 or 32 bit mode.

APS apsType Sets the Automatic Protection Switching mode to linear or ring topology.

customK1K2 Enables or disables customer K1K2 bytes.

k1NewState Allows the K1 byte code value to be sent in the Sonet frame.

k2NewState Allows the K2 byte code value to be sent in the Sonet frame.

Path Signal C2byteExpected The received path signal label.

C2byteTransmit The path signal label to be transmitted.

Error Handling

lineErrorHandling Enables line error handling.

pathErrorHandling Enables path error handling.




ppp and pppStatus

ppp allows for programming of the Point to Point protocol header, while pppStatus can be used to retrieve the current status and values of the PPP nego-tiation. The options of the two objects are integrated together in the next table. Items from pppStatus are indicated in underline mode. See “ppp” on page A-205 and “pppStatus” on page A-210 for full details.


TABLE 5-40. sonetError Options

Member Usage

insertionMode Controls whether an individual error is inserted periodically or continuously.

errorPerioderrorUnits

The frequency with which periodic errors are inserted, which may be expressed in seconds or frames.

consecutiveErrors The number of consecutive errors to be inserted at a time.

TABLE 5-41. sonetError Sub-Commands

Member Usage

setError Parameters associated with a particular error type are set in IxHal. A set command is needed to get these values into the hardware.

getError Reads back the values associated with a particular error type into the options described above.

startstop

Starts and stops periodic/continuous error insertion as programmed.

insertError Inserts a particular error for a single instance. setError and set must be used before this command.

TABLE 5-42. ppp/pppStatus Options


Basic enable Enables ppp negotiation.

Negotiation activeNegotiation Enables the active negotiation process.

enableAccmNegotiation Enables asynchronous control character negotiation.

enableIP Enables IP address negotiation

enableLqm Enables line quality monitoring negotiation.

enableOsi Enable OSI over PPP negotiation

enableMpls Enable MPLS over PPP negotiation



IP Addresses ipState The current state of IPCP negotiation

localIpAddress The local port’s IP address.

peerIpAddress The peer’s IP address.

Retries configurationRetries The number of configuration requests to try.

terminationRetries The number of termination requests to try.

Magic Number

useMagicNumber Enables the use of a magic number in the negotiation in order to discover looped back connections.

magicNumberNegotiated The magic number negotiated between the peers.

useMagicNumberRx/Tx Enable negotiation and use of the magic number in the receive direction/transmit direction.

Maximum Receive Unit

rxMaxReceiveUnit Maximum frame size in the receive direction.

txMaxReceiveUnit Maximum frame size in the transmit direction.

LQM lqmReportInterval The desired LQM interval to be used during LQM negotiation

lqmQualityState The current state of the LQM negotiation

lqmReportIntervalRx/Tx The negotiation LQM receive/transmit port interval

lqmReportPacketCounterRx/Tx

The number of LQM packets received/transmitted

OSI rxAlignmenttxAlignment

The desired byte alignment for reception/transmission used during negotiation

osiState The current state of OSI negotiation

rxAlignmenttxAlignment

The negotiated byte alignment for reception/transmission

MPLS mplsState The current state of MPLS negotiation

TABLE 5-42. ppp/pppStatus Options




hdlc

hdlc sets the three values associated with the HDLC header. See “hdlc” on page A-93 for full details.


frameRelay

frameRelay controls Frame Relay specific parameters. sonet config -header must be configred for the correct Frame Relay headers first. See “frameRelay” on page A-90 for full details.

The values set here are within the Frame Relay header. The important options of this command are:

TABLE 5-43. hdlc Options

Member Usage

address The one-byte address field.

control The one-byte control field.

protocol The two-byte protocol field.

TABLE 5-44. hdlc Sub-Commands

Member Usage

setCisco Sets the header variables to the Cisco defaults in IxHal.

setppp Sets the header variables to the ppp defaults in IxHal.

TABLE 5-45. frameRelay Options

Member Usage

addressSize The address length in the header.

becn Sets the backward congestion notification bit.

commandResponse Sets the command or response bit.

control Sets the control information bit.

discardEligibleBit Sets the discard eligible bit.

dlci The frame relay address field.

dlciCore Sets the DLCI core indicator bit.

etherType The ethernet type of protocol to use.

extensionAddress-0/1/2/3

Extension address bit 0/1/2/3.

fecn Sets the forward congestion notification bit.

nlpid The network layer protocol identifier for the upper-layer protocol.



bert and bertErrorGeneration

The bert command configures a BERT capable port. The pattern which is trans-mitted and/or received is programmed. bertErrorGeneration is used to insert errors into a transmitted stream. Received errors are available through the use of the stat command. The important options of the bert command are:

The important options and sub-commands of the bertErrorGeneration com-mand are:

portGroups Port groups provide a means of creating an group of ports on which an action may be performed or command may be sent. A single instance of portGroup may

TABLE 5-46. bert Options

Member Usage

txRxPatternMode Couples the expected receive pattern with the transmitted, or leaves it independent

txPatternIndextxUserPatternenableInvertTxPattern

Determines the transmitted pattern from one of a set or pre-programmed patterns or a user supplied pattern. The pattern may be inverted or not.

rxPatternIndexrxUserPatternenableInvertRxPattern

If the receive pattern is independently programmed form the transmitted pattern, determines the expected receive pattern from one of a set or pre-programmed patterns or a user supplied pattern. The pattern may be inverted or not.

TABLE 5-47. bertErrorGeneration Options

Member Usage

errorBitRateperiod

Determines the frequency, in bits, with which errors are inserted. The choice may be from a pre-programmed set or set to an arbitrary value.

burstCount The number of errors inserted at a time.

burstWidth The number of errors to insert at a time.

burstPeriod The number of good bits between error insertions.

bitMask A 32-bit mask indicating which bits within a 32-bit word are to be errored.

TABLE 5-48. bertErrorGeneration Sub-Commands

Member Usage

startContinuousError Starts the continuous insertion of programmed errors.

stopContinuousError Stops the continuous insertion of errors.

insertSingleError Inserts a single instance of the programmed error.



be used to maintain a number of groups. See “portGroup” on page A-201 for full details. The important options and sub-commands of this command are:

TABLE 5-49. portGroup Options

Member Usage

lastTimestamp The timestamp, a 64-bit number of nanoseconds, of when the last command was sent to the hardware as a result of a setCommand method execution.

TABLE 5-50. portGroup Sub-Commands

Member Usage

create Creates a new port group, identified by a unique number.

destroy Destroys a port group.

add Adds a port to a port group.

del Deletes a port from a port group.

canUse Tests to see whether the current user can use the ports in a group. That is, he/she owns the ports or they are not being used by someone else.

setCommand Performs an action or sends a command to all of the ports in a group:Transmit commands:• Start / stop• Staggered start• Pause• Step• Clear time stampReceive:• Start / stop capture• Reset statistics• Start / stop latency• Clear latencyProtocols:• Start/stop each of the protocolsOthers:• Take / clear ownership• Force take / clear ownership

write Sends port properties such as speed, duplex mode and autonegotiation to the hardware. All other values may be sent with writeConfig.

writeConfig Sends streams, filter and capture parameters to the hardware.


IxTclHal API DescriptionData Transmission

Data Transmission

Streams and Flows Streams and flows are the means by which data is applied to the DUT. Streams are generated ‘on the fly’ by the Ixia hardware. Flows are data arrays located on disk and associated with a port. Multiple streams are defined and associated with a port through the use of the stream command. stream provides for the transi-tions between streams, gaps, addressing and basic frame control. Additional commands are required for further packet header and data contents:

• udf—data in User Defined Fields, which may be algorithmically or manually generated.

• tcpRoundTripFlows–generate packets for round trip flow analysis.

• packetGroup–generate data for packet group latency measurements.

• dataIntegrity–generate additional data integrity values.

• Sequence Checking–generate data for additional sequence checking.

• forcedCollisions–generate deliberate collisions.

• protocol—establish basic protocol parameters.

• isl—set up header parameters for Cisco ISL.

• vlan—set up header parameters for VLANs.

• mpls and mplsLabel—generate MPLS headers and control messages.

• ipx—set up IPX header parameters.

• arp—generate ARP messages.

• ip—set up IP header parameters.

• tcp—set up TCP/IP header parameters.

• udp—set up UDP/IP header parameters.

• igmp—generate IGMP messages.

• icmp—generate ICMP messages.

• rip and ripRoute—generate RIP messages.

• dhcp—generate DHCP messages.

stream

stream controls the basic structure of streams: stream to stream transition, inter-stream/frame/burst gaps, and addressing. It also controls the common frame con-tents: size, base data pattern, checksum and identity record. The other commands in this section may be used for specific protocols and header data. Multiple streams may be created and connected to each other through the use of their IDs. See “stream” on page A-282 for full details.


IxTclHal API DescriptionData Transmission5

The important options and sub-commands of this command are:TABLE 5-51. stream Options


Stream Control enable This stream is enabled or not. Disabled streams are skipped during transmission.

dma The type of stream and relationship to another stream:• Continuous packet.• Continuous burst.• Stop after stream.• Advance to next stream.• Return to stream ID (labeled as

gotoFirst for historical rea-sons)

• Loop to stream ID (labeled as firstLoopCount for historical reasons)

returnToId The stream ID to return to for the return to and loop to stream ID dma types.

loopCount This is the repeat count for the dma choice ‘loop to stream ID’.

numBursts The number of bursts, ignored for dma choices continuous packet and continuous burst.

numFrames The number of maximum frames in a stream, ignored for dma choice continuous packet.

Inter-Frame Gap gapUnit The choice of units for ifg, isg and ibg. The choices are:• Nano-seconds• Micro-seconds• Milli-seconds• Seconds• Clock ticks—which vary with the

port type.

ifgType Indicates whether the inter-frame gap is a fixed value or random between a minimum (ifgMIN) and maximum value (ifgMAX).

ifg The inter-frame gap expressed in gapUnit units.

ifgMIN The minimum gap generated for ifgType of random.

ifgMAX The maximum gap generated for ifgType of random.



rateMode Indicates whether to use the ifg value or to calculate the ifg based on a percentage of the maximum transmission rate and infer the ifg value. Note: if the percentage rate is to be used instead of gap, then the stream config -rateMode percentMaxRate should immediately follow the initial stream setDefault command.

percentPacketRate

If rateMode indicates, the ifg is calculated based on a desired percentage of maximum transmission rate.

framerate (Read-only) The actual rate, in frames per second that the stream will transmit at.

Inter-Burst Gap enableIbg Enables the use of inter-burst gaps.

ibg The inter-burst gap expressed in gapUnit units.

Inter-Stream Gap enableIsg Enables the use of inter-stream gaps.

isg The inter-stream gap expressed in gapUnit units.

Addressing da First destination MAC address assigned to the stream.

daMaskValue/daMaskSelect

Indicates which bits of the destination MAC address are to be manipulated and their initial values.

numDA The number of destination MAC addresses that will be used.

daRepeatCounter Indicates how the destination MAC address is to be incremented or decremented from packet to packet.

sa First source MAC address assigned to the stream.

saMaskValue/saMaskSelect

Indicates which bits of the source MAC address are to be manipulated and their initial values.

numSA The number of source MAC addresses that will be used.

saRepeatCounter Indicates how the source MAC address is to be incremented or decremented from packet to packet.

TABLE 5-51. stream Options




Frame Control frameSizeType The type of frame size calculation:• Fixed size as indicated in

framesize.• Random size between

frameSizeMin and frameSizeMax.

• Incrementing packet to packet.• Automatically calculated, depend-

ing on protocol dependent con-tents.

framesize The size of all frames if frameSizeType is fixed.

frameSizeMin The minimum frame size if frameSizeType is random.

frameSizeMax The maximum frame size if frameSizeType is random.

frameType The type field of the Ethernet frame.

preambleSize Number of bytes in the frame preamble.

patternType Dictates the type of data pattern manipulation:• increment/decrement bytes or

words• random data• fixed repeating pattern chosen

from dataPattern• fixed non-repeating pattern cho-

sen from dataPattern

dataPattern One of a number of fixed patterns of data, including all 1’s and all 0’s, plus a choice for a user specified pattern.

pattern If dataPattern indicates a user specified pattern, this string specifies the contents.

fcs The type of FCS error to be inserted into the frame (or none).

fir Whether to insert a Frame Identity Record into the last 6 bytes of the packet.





Frame Data Misc

udf

Up to four User Defined Fields may be defined, which allow arbitrary data to be algorithmically constructed within the data portion of the frames. The get stream sub-command must be called before get udf sub-command and set stream sub-command must be called after set udf sub-command. See “udf” on page A-303 for full details.


Misc asyncIntEnable Allow asynchronous interrupts required by the protocol server.

packetView (Read-only) Shows the packets that are about to be transmitted. If the port’s port.transmitMode is set to portTxPacketFlows, then this displays all of the packets to be transmitted. This data may be saved and used to specify a port.packetFlowFileName.

TABLE 5-52. stream Sub-Commands

Member Usage

setGaps Sets the ifg, isg and ibg to a single value and then commits them to hardware.

setIFG Sets the ifg to a specified value and then commits it to hardware.

setLoopCount Sets the loopCount member to a specified value and commits it to hardware.

setNumFrames Sets the numFrames member to a specified value and commits it to hardware.



TABLE 5-53. udf Options

Member Usage

enable Enable or disable this UDF definition.

offset The offset within the packet to place the UDF data.

countertype The size and shape of the UDF counter. One to four 32 to 8 bit counters.

random If set, all counters have random data.

continuousCount If set, all counters operate continuously.



tcpRoundTripFlows

The tcpRoundTripFlows command sets up values to be used in measuring round-trip times. See “tcpRoundTripFlow” on page A-294 for full details.


repeat If continuousCount is not set, this is the repeat count for all counters.

updown A four-bit mask indicating whether each counter counts up or down.

initval The initial value of the counter.

maskselect/maskval

Together these indicate which initial value bits to use and increment/decrement.

enableCascade For PoS ports, enables a counter to continue with a count from stream to stream.

TABLE 5-54. tcpRoundTripFlows options


Data patternType Dictates the type of data pattern manipulation:• increment/decrement bytes or words• random data• fixed repeating pattern chosen from

dataPattern• fixed non-repeating pattern chosed from

dataPattern

dataPattern One of a number of fixed patterns of data, including all 1’s and all 0’s, plus a choice for a user specified pattern.

pattern If dataPattern indicates a user specified pattern, this string specifies the contents.

framesize The number of bytes in each package.

Addresses macSA The source MAC address used for outbound packets.

macDA The destination MAC address used for outbound packets. This may be overridden through the use of useArpTable.

useArpTable If set, the ARP table is used instead to set the MAC address based on the destination IP address. gatewayIpAddr is used for the ARP query.

gatewayIpAddr If useArpTable is set, this is the address of the gateway that will respond to ARP requests.

TABLE 5-53. udf Options

Member Usage



packetGroup

The packetGroup command sets up values to be used in measuring latency, classed by tagged groups of packets. See“Packet Group Operation” on page 3-11 for a description of this feature. See “packetGroup” on page A-178 for full details. In order to calculate latency values the fir object in the stream command should be set to true and the value of the port’s receiveMode option should be set to portPacketGroup.

The important members and methods of this class are:

forceIpSA If set, IpSA is used to set the outbound IP address.

IpSA Outbound IP source address.

TABLE 5-55. packetGroup Options


Signature signatureOffset Where to place the signature in each transmitted packet.

signature The signature to be inserted at the signature offset.

insertSignature Whether to insert the signature or not.

Packet ID groupIdOffset Where to place the group ID in each transmitted packet.

groupId The value to use as the packet group ID.

Receive mode preambleSize The expected size of the received preamble.

latencyControl The type of latency measurement:• cutThrough – first data bit in to first

data bit out storeAndForward – last data bit in to first data bit out

• storeAndForwardPreamble – last data bit in to first preamble out

TABLE 5-56. packetGroup Sub-Commands

Member Usage

setTx Sets the packet group transmit characteristics for the port.

getTx Gets the packet group transmit characteristics for the port.

setRx Sets the packet group receive characteristics for the port.

getRx Gets the packet group receive characteristics for the port.

TABLE 5-54. tcpRoundTripFlows options




dataIntegrity

The dataIntegrity class sets up values to be used to check data validity. See“Data Integrity Checking Operation” on page 3-13 for a description of this feature. In order for data integrity to operate, port -receiveMode portRxDataIntegrity must be performed (and committed to the hardware). See “dataIntegrity” on page A-65 for full details.


Sequence Checking

There is no specific command that controls the operation of sequence checking. Instead, the following steps should be used to enable sequence checking:

1. Set the value of the port’s receiveMode option to portRxSequenceChecking.

2. Set the location of the signature in the packet via the signatureOffset and signature members of the packetGroup command.

3. Set the location of the sequence check value via the groupIdOffset mem-ber of the packetGroup class.

4. Set the values to the hardware via the setTx sub-command of the TclPacketGroup command.

5. The statistics values signatureErrors and signatureValues relate to signature checking. Refer to “stat” on page A-262.

TABLE 5-57. dataIntegrity Options


Signature signatureOffset Where to place the signature in each transmitted packet.

signature The signature to be inserted at the signature offset.

insertSignature Whether to insert the signature or not.

Receive mode enableTimeStamp Enables the placement of a 48-bit timestamp just before the FCS value with a 20ns accuracy.

TABLE 5-58. dataIntegrity Sub-Commands

Member Usage

setTx Sets the data integrity transmit characteristics for the port.

getTx Gets the data integrity transmit characteristics for the port.

setRx Sets the data integrity receive characteristics for the port.

getRx Gets the data integrity receive characteristics for the port.



forcedCollisions

Collisions may be forced on the data transmission from any port. Refer to “Forced Collision Operation” on page 3-10 for the full discussion of this feature and to “forcedCollisions” on page A-87 for command details. The important members and methods of this class are:

Protocols

The following commands relate to protocol selection, header options and, in some cases, message formatting.

protocol

Basic protocol parameters are set with the protocol command. See “protocol” on page A-213 for full details. The important options of this command are:

TABLE 5-59. forcedCollisions Members

Member Usage

enable Enables forced collisions.

packetOffset The offset from the beginning of packet to the start of the collision.

collisionDuration The duration of each collision

consecutiveCollisions The number of consecutive collisions to generate at a time.

consecutiveNonCollidingPackets

After each time that collisions have occurred, this is the number of packets that will not be modified.

continuous Indicates that collisions are to occur continuously.

repeatCount If continuous operation is not selected, the number of times to repeat the cycle of collisions and non-collisions.

TABLE 5-60. protocol Options


Protocol appName The protocol above IP: UDP, ARP, RIP or DHCP.

name Protocol selected: MAC, IPv4, IPv6 and IPX.

Data Link Layer enable802dot1qTag Enables 802.q Vlan tagged frames.

enableISLtag Enables Cisco ISL tagged frames.

enableMPLS Enables MPLS tagged frames.

ethernetType Type of ethernet frame: EthernetII, IEEE802.3, IEEE802.3 Snap or IEEE802.2



Data Link Layer

isl

The isl command sets up the header for Cisco ISL messages. The enableISLtag option of the protocol command must be set. The data por-tion of the message may be created using stream. See “isl” on page A-139 for full details.


vlan

The vlan command sets up the header for VLAN specific messages. The enable802dot1qtag option of the protocol command must be set. The data portion of the message may be created using stream. See “vlan” on page A-314 for full details. The important options of this command are:

TABLE 5-61. isl Options

Member Usage

islDA The multicast address indicating to the receiver that this is an ISL formatted packet.

frameType The type of frame being encapsulated:• Ethernet• Token Ring• FDDI• ATM

userPriority Two bits of packet priority.

islSA (Read-only) The source MAC address. The upper three bytes are reflected in the hsa field.

hsa The high order three bytes of the source address, corresponding to the manufacturers ID.

vlanID The virtual LAN identifier.

bpdu Set for all Bridge Protocol Data Units that are encapsulated by the ISL packet.

index For diagnostic purposes, the port index of the packet as it exits the switch.

encapDA The encapsulated frame’s destination MAC address.

encapSA The encapsulated frame’s source MAC address.

TABLE 5-62. vlan Options

Member Usage

userPriority User priority level.

cfi Canonical format indicator bit.



mpls

The enableMPLS member of the associated protocol command must be set to successfully use this command. The mpls command sets up the base information for MPLS specific messages. The data portion of the message may be created using mplsLabel. See “mpls” on page A-151 for full details. The important options of this command are:

mplsLabel

The enableMPLS member of the associated protocol object must be set to suc-cessfully use this command. The mplsLabel command is used to generate MPLS labels. See “mplsLabel” on page A-154 for full details. The important options of this command are:

vlanID The VLAN identifier.

mode Indicates whether the VLAN tag will be incremented/decremented or random between packets.

repeat For each new value of the VLAN ID, this is the number of times it is repeated before the next change.

maskval This masks the values of the VLAN ID that may be changed.

TABLE 5-63. mpls Options

Member Usage

type The MPLS type: unicast or multicast.

forceBottomOfStack Automatically set bottom of stack bit.

TABLE 5-64. mpls Options

Member Usage

label The value of the label:• IPV4 Explicit Null• Router Alert• IPV6 Explicit Null• Implicit Null• Reserved

experimentalUse Sets the experimental use field.

bottomOfStack Sets the bottom of stack bit.

TABLE 5-62. vlan Options

Member Usage



IPX

ipx

The ipx command provides for the setting of IPX header elements. See “ipx” on page A-122 for full details. The important options of this command are:

TABLE 5-65. ipx options


Source sourceNetwork The network number of the source node.

sourceNetworkCounterMode Indicates whether the network number will increment, decrement or receive a random setting.

sourceNetworkRepeatCounter The number of times that the network number will change.

sourceNetworkMaskValuesourceNetworkMaskSelect

Together these set the mask of network number bits that will change.

sourceNodesourceNodeCounterModesourceNodeRepeatCountersourceNodeMaskValuesourceNodeMaskSelect

As in sourceNetwork... for the sourceNode.

sourceSocketsourceSocketCounterModesourceSocketRepeatCountersourceSocketMaskValuesourceSocketMaskSelect

As in sourceNetwork... for the sourceSocket.

Destination destNetworkdestNetworkCounterModedestNetworkRepeatCounterdestNetworkMaskValuedestNetworkMaskSelect

As in sourceNetwork... for the destNetwork.

destNodedestNodeCounterModedestNodeRepeatCounterdestNodeMaskValuedestNodeMaskSelect


destSocketdestSocketCounterModedestSocketRepeatCounterdestSocketMaskValuedestSocketMaskSelect




ARP

arp

The name of the associated protocol object must be set to ‘ip’ and the appName must be set to ‘arp’ to successfully use this command.The arp com-mand allows ARP packets to be constructed. See “arp” on page A-2 for full details.


Misc length The total length of the IPX packet, including header. May be set if lengthOverride is set.

lengthOverride Allows the length value to be changed.

packetType The type of IPX packet.

transportControl The number of routers that the packet has passed through.

TABLE 5-66. arp options


Basic operation The type of ARP operation:• ARP Request• ARP Reply• Reverse ARP Request• Reverse ARP Reply

Physical hardwareAddrLength (Read-only) The length of the hardware address.

hardwareType (Read-only) The hardware type of the physical layer.

protocolAddrLength (Read-only) The length of the protocol addresses.

protocolType (Read-only) The type of network protocol address.

Source sourceHardwareAddr The MAC address of the sender.

sourceProtocolAddr The protocol address of the sender.

Destination destHardwareAddr The MAC address of the receiver.

destProtocolAddr The protocol address of the receiver.

TABLE 5-65. ipx options




IP

ip

The ip command allows IPv4 header values to be constructed. The name of the associated protocol object must be set to ‘ip’ to successfully use this com-mand. See “ip” on page A-112 for full details.

The important options of this command are:TABLE 5-67. ip Options


Header precedencedelaythroughputreliabilitycostreserved

The parts of the Type of Service (TOS) byte.

totalLength The total length of the IP packet, including header. This may be overridden from the automatically calculated setting if lengthOverride is set.

lengthOverride Allows the totalLength of the packet to be overridden from the calculated setting.

identifier An identifier used to re-assemble fragments.

fragment Indicates whether this is a fragmented datagram.

fragmentOffset For fragmented packets, the offset in the re-assembled datagram where this packet’s data belongs.

lastFragment Indicates that this is the last fragment of the datagram.

ttl Time to live for packet, in seconds.

ipProtocol The next level protocol contained in the data portion of the packet.

useValidChecksum Indicates whether a valid or invalid checksum should be included in the header.

checksum (Read-only) The value of the header checksum. Only valid after stream.set is performed.

Source sourceIpAddr The source IP address.



tcp

The name of the associated protocol object must be set to ‘ip’ and the ipProtocol member of the associated ip object must be set to ‘tcp’ to success-fully use this command. The tcp command allows TCP header values to be con-structed. See “tcp” on page A-291 for full details. The important options of this command are:

sourceIpAddrMode Indicates how the IP address will change from packet to packet: remain the same, increment/decrement host or network or random values.

sourceIpAddrRepeatCount The number of different source addresses generated.

sourceIpMask The source IP subnet mask.

sourceCommand The command type for the source address: A, B, C, D or no command.

Destination destIpAddr The destination IP address.

destIpAddrMode Indicates how the IP address will change from packet to packet: remain the same, increment/decrement host or network or random values.

destIpAddrRepeatCount The number of different destination addresses generated.

destIpMask The destination IP subnet mask.

destCommand The command type for the destination address: A, B, C, D or no command.

Misc options Variable length options field.

destDutIpAddr The address of the device under test.

destMacAddr The MAC address of the device under test. Received ARP frames will modify this value.

TABLE 5-68. tcp options


Header offset Offset from the beginning of the header to the packet data.

sourcePort Source port number.

TABLE 5-67. ip Options




udp

The name of the associated protocol object must be set to ‘ip’ and the appName member must be set to ‘udp’ to successfully use this command.The udp command is used to format UDP headers. See “udp” on page A-307 for full details. The important options of this command are:

destPort Destination port number.

sequenceNumber Packet sequence number.

acknowledgementNumber

Next byte that the receiver expects.

window The number of bytes the recipient may send back, starting with the ack byte.

urgentPointer Byte offset to urgent data with the packet, if any.

options Variable length set of options.

Flags urgentPointerValid Indicates whether the urgentPointer field is valid.

acknowledgeValid Indicates whether the acknowledementNumber is valid.

pushFunctionValid Request that the receiver push the packet to the receiving application without buffering.

resetConnection Resets the connection.

synchronize Indicates either a connection request or acceptance.

finished Indicates that this is the last packet to be sent for the connection.

TABLE 5-69. udp Options

Member Usage

sourcePort Port of the sending process.

destPort Port of the destination process.

length Length of the datagram including the header. If lengthOverride is set, this value is used instead of the calculated value.

lengthOverride Allows the length parameter to be used to set the packet length.

enableChecksum Causes a valid or invalid checksum to be generated in the UDP header.

TABLE 5-68. tcp options




igmp

The name of the associated protocol object must be set to ‘ip’ and the ipProtocol member of the associated ip object must be set to ‘igmp’ to suc-cessfully use this command. The igmp command is used to format IGMP mes-sages. See “igmp” on page A-102 for full details. The important options of this command are:

icmp

The name of the associated protocol object must be set to ‘ip’ and the ipProtocol member of the associated ip object must be set to ‘icmp’ to suc-cessfully use this command. The icmp command is used to format ICMP mes-sages. Any data not covered in the options below must be entered in the stream’s data portion. See “icmp” on page A-98 for full details. The important options of this command are:

checksum The actual value generated. Valid only after stream.set has been used.

enableChecksumOverride

Enables the setting of a checksum from checksum.

TABLE 5-70. igmp Options

Member Usage

version Which version of IGMP to use: 1 or 2.

type The type of IGMP message to generate:• membership Query• membership Report—type 1 or 2.• DVMRP Message—Distance Vector Multicast Rout-

ing Protocol• Leave Group

maxResponseTime The maximum allowed response time.

groupIpAddress The IP multicast address of the group being joined or left.

mode Describes how groupIpAddress will change from one message to the next: idle, increment or decrement.

repeatCount The number of IGMP messages to send.

TABLE 5-71. icmp Options

Member Usage

type The type of ICMP message to be sent.

code The code for each type of message.

checksum (Read-only) The value of the checksum to be sent in the stream. This is only valid after stream.set is used.

TABLE 5-69. udp Options

Member Usage



rip

Note: the rip and ripRoute commands allow you to create RIP packets for trans-mission as part of a stream. They are not associated with the RIP aspect of the Protocol Server, described in RIP on page 5-80. The name of the associated protocol object must be set to ‘ip’ and the appName member of the associated protocol object must be set to ‘Rip’ to successfully use this command. The rip command is used to configure the RIP header. Individual RIP route entries are associated with the ripRoute command and the use of RouteIds. See “rip” on page A-222 for full details. The important options of this command are:

ripRoute

The ripRoute command is used to format RIP route messages. Header infor-mation is contained in the associated rip command. See “ripRoute” on page A-225 for full details. The important options of this command are:

id ID for each echoRequest type message.

sequence Sequence number for each echoRequest type message.

TABLE 5-72. rip Options

Member Usage

command The RIP command. One of:• RIP Request• RIP Response• RIP Trace On• RIP Trace Off• RIP Reserved

version The RIP version: 1 or 2.

TABLE 5-73. ripRoute Options

Member Usage

familyId Address family identifier.

routeTag Used to distinguish multiple sources of routing information.

ipAddress IP address of the entry.

subnetMask Subnet mask for the entry.

nextHop For version 2 records only, the IP address of the next routing hop for the entry.

metric The cost of the route, from 1 to 16.

authenticationType The type of authentication to use.

authentication Data associated with the authentication method.

TABLE 5-71. icmp Options

Member Usage



dhcp

The name of the associated protocol object must be set to ‘ip’ and the appName member of the associated protocol object must be set to ‘Dhcp’ to successfully use this command. The dhcp command is used to format DHCP messages. Multiple options are entered into the message through repeated use of the setOption method. See “dhcp” on page A-69 for full details. The important options and sub-commands of this command are:

TABLE 5-74. dhcp Options

Member Usage

opCode Operation code:• DHCP Boot Request• DHCP Boot Reply

hwType Hardware address type.

hwLen Hardware address length.

hops Set to 0 to indicate packet origin.

transactionID Random identifier for message pairing.

seconds Elapsed time since start of request.

flags Indicates broadcast or non-broadcast handling.

clientIpAddr Client’s IP address.

yourIpAddr Your IP address.

relayAgentIpAddr Relay agent’s IP address; used if booting through a proxy.

clientHWAddr Client’s hardware address.

serverHostName Optional server host name.

serverIpAddr Server’s IP address.

bootFileName Boot file name to use.

optionCode Code for optional data.

optionDataLength Length of the option data.

optionData The actual data.

TABLE 5-75. dhcp Sub-Commands

Member Usage

setOption Sets an option value.

getOption Gets a previously set option.


IxTclHal API DescriptionData Capture and Statistics5

Data Capture and StatisticsData is captured as a result of the use of four commands:

• filter—sets up conditions under which data capture is triggered and fil-tered. filter sets up the conditions for collecting several user defined statis-tics.

• filterPallette—sets up address and pattern matches used in filter.

• capture—sets up basic sizing parameters for captured data.

• captureBuffer—sets up conditions under which QoS statistics will be gathered.

Raw data and statistics are then collected through the use of three commands:

• captureBuffer—provides access to the raw data and latency/jitter mea-surements.

• stat—provides access to all of the port statistics.

• statGroup and statList—provides access to average latency data and timestamps during packet group operation.

filter filter sets up the conditions under which data capture is triggered and filtered. Conditions for the collection of user defined statistics (UDS) 1, 2, 5 and 6 are also specified. User defined statistics 5 and 6 are also known as async trigger 1 and 2. See “filter” on page A-76 for full details.

There are six sets of eight options for the capture trigger and filter and the four user UDFs. These six contribute a prefix to the option name:• captureTrigger...

• captureFilter...

• userDefinedStat1...

• userDefinedStat2...

• asyncTrigger1...

• asyncTrigger2...


IxTclHal API DescriptionData Capture and Statistics

The eight options for the suffix to these names:

For example, at a minimum the Enable option of the captureTrigger com-mand and the Enable option of the captureFilter command must be set for any data to be captured.

filterPallette filterPallete sets up address and data pattern matching criteria used in filter. See “filterPallette” on page A-83 for full details.

TABLE 5-76. filter Options

Member Usage

Enable Enables or disables the filter, trigger or statistic.

DA Two destination address matches (DA1 and DA2) are set up through the use of filterPallette. This member chooses which conditions relating to those addresses are required for a match:• Any address• DA1• Not DA1• DA2• Not DA2

SA Two source address matches (SA1 and SA2) are set up through the use of filterPallette. This member chooses which conditions relating to those addresses are required for a match:• Any address• SA1• Not SA1• SA2• Not SA2

Pattern Two pattern matches (pattern1 and pattern2) are set up through the use of filterPallette. This member chooses which conditions relating to those pattern matches are required for a match:• Any address• pattern1• Not pattern1• pattern2• Not pattern2• pattern1 and pattern2

Error The error condition under which a match will occur including: • Anytime, without concern over errors.• Only for good packets• Any of a number of other error conditions.

FrameSizeEnable Enables or disables the size constraint as specified in the two entries below.

FrameSizeFromFrameSizeTo

The minimum and maximum frame size for a match.



There are four sets of two options for the source and destination addresses 1 and 2. These are:

There are two sets of four options for each of the two data patterns. These are:

capture capture sets up the basic parameters associated with the capture buffer usage. See “capture” on page A-45 for full details. The important options of this com-mand are:

TABLE 5-77. filterPallete Options - DA/SA

Member Usage

DA1 Destination address 1 data.

DAMask1 Mask of valid bits for destination address 1.

DA2 / DAMask2 Same for destination address 2.

SA1 / SAMask1 Same for source address 1.

SA2 / SAMask2 Same for source address 2.

TABLE 5-78. filterPallette Options - Pattern 1/2

Member Usage

matchType1 The basic form of match performed. This is a one of a number of pre-programmed choices in which the packet type and data pattern are pre-programmed and/or specially interpreted. One additional choice allows for user specification of the data and type.

patternOffset1 If the user choice is made in matchType1, this is the offset of pattern 1 in the frame.

pattern1 The data within the pattern to match for. For the pre-programmed choices in matchType1, this pattern has a special interpretation.

patternMask1 The mask to apply against pattern1 in order to obtain a match.

patternOffset2matchType2pattern2patternMask2

The same as for pattern 1, but for pattern 2.

TABLE 5-79. capture Options

Member Usage

sliceOffset The offset within the frame from which to begin capturing data.

sliceSize The maximum number of octets per frame to capture. 8192 is the largest slice size supported.

nPackets (Read-only) The actual number of packets available in the capture buffer.



captureBuffer captureBuffer allows the raw captured data to be obtained, or calculated latency data to be viewed. Data is held in the hardware until the get method is called, which copies the captured data for a range of frame numbers into local computer memory. Following the use of get, getframe will make an individ-ual frame available. Latency and deviation values may be calculated, subject to constraints through the use of setConstraint and getStatistics. Latency is defined as the difference between the transmit and receive times, in nanosec-onds. Jitter is defined as the deviation of the latency. See “captureBuffer” on page A-49 for full details.

The important options and sub-commands of this command are:TABLE 5-80. captureBuffer Options


Data frame (Read-only) The contents of the selected frame based on capture.sliceOffset and sliceSize.

length (Read-only) The total length of the frame, regardless of the slice captured.

numFrames The number of frames in the hardware’s capture buffer. After setConstraints is called, this value is updated with the number of frames that met the constraints.

status The status of the frame: either no errors, or one of a number of possible error conditions.

timestamp The arrival time of the captured frame in nanoseconds.

Measurements averageLatency (Read-only) The average latency of the frames in the retrieved capture buffer.

latency (Read-only) The frame’s latency.

minLatency (Read-only) The minimum latency of the frames in the retrieved capture buffer.

maxLatency (Read-only) The maximum latency of the frames in the retrieved capture buffer.

averageDeviation (Read-only) The average deviation of the average latencies of the frames in the retrieved capture buffer.

standardDeviation (Read-only) The standard deviation of the average latencies of the frames in the retrieved capture buffer.



The following example will import a previously saved capture buffer and print out the number of bytes in each frame:captureBuffer import d:/adrian.cap 1 1 1set numRxPackets [captureBuffer cget -numFrames]ixPuts "$numRxPackets packets in buffer"for {set frame 1} {$frame <= $numRxPackets} {incr frame} {captureBuffer getframe $frameset capframe [captureBuffer cget -frame]ixPuts "Frame $frame is [llength $capframe] bytes long"

Constraints enableEthernetType Enables jitter calculations to occur only over those frames with the ethernet type indicated in ethernetType.

ethernetType If enableEthernetType is set, this is the ethernet type to match on.

enableFramesize Enables jitter calculations to occur only over those frames with the frame size indicated in framesize.

framesize If enableFramesize is set, this is the frame size to match on.

enablePattern Enables jitter calculations to occur only over those frames with a pattern match as indicated in patternOffset and pattern.

patternOffset If enableFramesize is set, this is the expected offset within the frame for the pattern match.

patternOffset If enableFramesize is set, this is the expected pattern for the pattern match.

TABLE 5-81. captureBuffer Sub-Commands

Member Usage

get Copies the data for a range of frame numbers from the hardware capture buffer.

getFrame Gets an individual frame’s data.

clearConstraint Clears the constraint values for jitter calculation.

setConstraint Sets a new set of jitter calculation constraints.

getConstraint Gets the current set of jitter calculation constraints.

getStatistics Gets the jitter statistics for the current set of constraints.

export Export the contents of a capture buffer for later import or usage by another program.

import Import a previously saved and exported capture buffer for analysis.

TABLE 5-80. captureBuffer Options




}

stat Provides access to a wide range of statistics; the instantaneous value or rate is retrieved. See “stat” on page A-262 for full details. Statistics may be gathered in several ways:

• Statistics in bulk, through the use of the stat get allStats <chassis> <card> <port> followed by calls to get the data using stat cget -statName.

• Rate statistics in bulk, through the use of the stat getRate allStats <chassis> <card> <port> followed by calls to get the data using stat cget -statName.

• An individual statistic, through the use of the stat get statName <chassis> <card> <port>. The values is returned from the call.

• An individual rate statistic, through the use of the stat getRate statName <chassis> <card> <port>. The value is returned from the call.

Note also that most of the statistics are 64-bit values. mpexpr should be used to perform calculations on these values. The important options and sub-commands of this command are:

TABLE 5-82. statistics Options

Member Usage

mode Sets the mode of the counters:• Normal.• QoS—reuses eight of the counters for QoS values.• UDS 5,6—reuses two of the counters for User Defined Sta-

tistics 5 and 6.• Checksum Errors—reuses six hardware counters for IP,

TCP and UDP checksum errors.• Data Integrity—reuses two counters for data integrity errors.

<statistics> The number and type of statistics is too large to mention here. See “stat” on page A-262 for a description of the stat command and Appendix G - Available Statistics for description of all statistics available.

TABLE 5-83. statistics Sub-Commands

Member Usage

get Gets a particular statistic value or all statistics.

getRate Gets the frame rate for a particular statistic value or all statistics.

getCaptureState Determines whether a port’s capture buffer is active or idle.

getLinkState Gets the link state for a port.



statGroup and statList

These commands provide an alternate means for accessing statistics across a set of ports. See “statGroup” on page A-279 and “statList” on page A-281 for full details. A group is formed using statGroup and all of the valid statistics for the ports in the group are available through statList:

Note also that most of the statistics are 64-bit values. mpexpr should be used to perform calculations on these values. The important options and sub-commands of statGroup are:

The important options and sub-commands of statList are:

getTransmissionState Determines whether a port is actively transmitting or idle.

set Sets the port’s statistics mode as indicated in the mode member.

TABLE 5-83. statistics Sub-Commands

Member Usage

TABLE 5-84. statGroup Options

Member Usage

numPorts The current number of ports in the group.

TABLE 5-85. statGroup Sub-Commands

Member Usage

setDefault Resets the list to empty.

add Adds a port to the group.

del Deletes a specific port from the group.

get Retrieves all of the valid statistics for all of the ports in the group. The individual statistics are available through statList.

TABLE 5-86. statList Options

Member Usage

<statistics> The number and type of statistics is too large to mention here. See “stat” on page A-262 for a description of the stat command and Appendix G - Available Statistics for description of all statistics available.

TABLE 5-87. statList Sub-Commands

Member Usage

get Gets a particular statistic value or all statistics.

getRate Gets the frame rate for a particular statistic value or all statistics.



qos qos allows the user to set up the QoS counter filters and offsets. See “qos” on page A-219 for full details. The important options and sub-commands of this command are:

packetGroupStats packetGroupStats is used to retrieve statistics related to packet groups. The get method must be used to get the data related to a number of groups, followed by a call to getGroup for a particular group number. See “packetGroupStats” on page A-183 for full details. The important options and sub-commands of this command are:

TABLE 5-88. qos Options

Member Usage

patternOffset The offset in the frame where a particular pattern will be matched before QoS counting will occur.

patternMatch The value to look for at the patternOffset.

patternMask The mask to be applied in the pattern match.

byteOffset The offset in the packet where the priority value is located - to be used to increment the correct QoS counter.

TABLE 5-89. qos Sub-Commands

Member Usage

setup Sets the QoS counters for certain types of packets:• Ethernet II• 802.3 Snap• VLAN• ppp• Cisco HDLC

TABLE 5-90. packetGroupStats options


Basic numGroups The number of actual groups received.

totalFrames The total number of frames used to calculate the statistics.

Latency averageLatencyminLatencymaxLatency

The average/min/max latency for a group.

Time Stamps firstTimeStamp Transmission start time.

lastTimeStamp Transmission stop time.

Bit Rate bitRate The bit rate. Note that this requires multiple calls to get before valid values are obtained.



TABLE 5-91. packetGroupStats Sub-Commands

Member Usage

get Used to get the data for a range of group IDs into local memory.

getGroup Used to retrieve the latency for a particular group.


IxTclHal API DescriptionProtocol Server

Protocol ServerThe protocol server implements a number of intelligent, bi-directional test Sub-Commands and data gathering routines:

• IP—constructs an IP address to MAC address correspondence table.

• ARP—sends ARP requests and maintains an IP address to MAC address cor-respondence table based on responses.

• IGMP—sends and responds to IGMP messages.

• BGP4—simulates one or more BGP4 routers in a network of routers.

• OSPF—simulates one or more OSPF routers in a network of routers.

• IS-IS–simulates one or more routers IS-IS routers in a network of routers.

• RSVP-TE–simulates one or more RSVP ingress or egress routers. Concen-trates on Traffic Engineering parameters.

• RIP–simulates one or more RIP routers in a network of routers.

protocolServer The protocolServer command enables/disables each of the protocol servers and provides the first entry for the IP address table. See “protocolServer” on page A-216 for full details.


IP Please refer to “IP” on page 3-17 for a discussion of the Ixia Protocol Server’s testing model with respect to IP.

ipAddressTable

The address table is a list of entries, each of which is described in the item com-mand. The address table command is used to position within the list and elements

TABLE 5-92. protocolServer Options

Member Usage

enableArpResponse (Non-PoS cards only) Enables ARP requests and responses.

enableBgp4Response Enables BGP4 testing.

enableIgmpQueryResponse Enables IGMP testing.

enableIsisResponse Enables ISIS testing

enableOspfResponse Enables OSPF testing.

enablePingResponse Enables PING requests and responses.

enableRipResponse Enables RIP testing

enableRsvpResponse Enables RSVP testing


IxTclHal API DescriptionProtocol Server5

are accessed with the list object. The typical series of operations is shown in the table below:

See “ipAddressTable” on page A-118 for full details. The important options and sub-commands of this command are:

TABLE 5-93. Typical Address Table Operations

Operation Steps

add address table items

1. Set values in the ipAddressTableItem command.

2. Use the set sub-command of the ipAddressTableItem command which transfers the data into a holding area.

3. Use the addItem sub-command of the ipAddressTable command to move the data from the holding area to the actual list.

4. Repeat steps 1, 2 and 3 for each table item to be added.

5. Use the set sub-command of the ipAddressTable command to send the table to the hardware.

look through address table

1. Use the get sub-command ipAddressTable com-mand to transfer the data from the hardware to the object.

2. Use the get sub-command of the ipAddressTableItem command to get the data into the ipAddressTableItem options.

3. Use the getNextItem sub-command of the ipAddressTable command to position to the next table item.

4. Repeat steps 2 and 3 until an error is returned from step 3.

find the address table item for an IP address

1. Use the getItem sub-command of the ipAddressTable command to position the list to the correct entry.

2. Use the get sub-command of the ipAddressTableItem command to get the data into the ipAddressTableItem options.

TABLE 5-94. ipAddressTable Options

Member Usage

defaultGateway The IP address of where all non-overridden ARP requests are sent. This is usually the address of the Device Under Test.



ipAddressTableItem

This command holds an individual table item; ipAddressTable takes care of keeping the actual list of address table items. See “ipAddressTableItem” on page A-120 for full details. The important options and sub-commands of this com-mand are:

TABLE 5-95. ipAddressTable Sub-Commands

Member Usage

clear Clears the IP address table.

addItem Adds the address table item as set by the last call to ipAddressTableItem.set to the address table at the current table position.

delItem Deletes the address table item at the current position.

getItem Finds the address table item for a particular IP address.

getFirstItem Positions to the first address table item.

getNextItem Moves to the next address table item.

TABLE 5-96. addressTableItem Options

Member Usage

fromIpAddresstoIpAddress

The IP address range.

fromMacAddresstoMacAddress

The MAC address range.

numAddresses The number of consecutive addresses.

enableUseNetworknetMask

Enables and sets the network mask to be applied to the IP addresses.

overrideDefaultGateway Override the default gateway address from the protocolServer object.

gatewayIpAddress If the gateway is overridden, this is the new gateway address value.

mappingOption IP to MAC mapping: either one IP to one MAC or many IP to one MAC.

TABLE 5-97. addressTableItem Sub-Commands

Member Usage

get Gets the current item from the ipAddressTable command.

set Saves the current item for use by ipAddressTable.



ARP Please refer to “ARP” on page 3-17 for a discussion of the Ixia Protocol Server’s testing model with respect to ARP.

arpServer

The ARP table is automatically populated when ARP responses are received from automatically generated ARP requests. The arpAddressTableEntry command operates in concert with arpServer to show the entries in the table. The arpServer object sets the position in the list and arpAddressTableEntry access the entry at the current position. The typical series of operations is shown in the table below:

See “arpServer” on page A-8 for details. The important options and sub-com-mands of this command are:


Operation Steps

look through ARP table

1. Use the get sub-command of the arpServer com-mand to transfer the data from the hardware to the object.

2. Use the get sub-command of the arpAddressTableEntry command to get the data into the arpAddressTableEntry options.

3. Use the getNextItem sub-command of the arpServer command to position to the next table item.


find the ARP table item for an IP address

1. Use the getItem sub-command of the arpServer command to position the list to the correct entry.

2. Use the get sub-command of the arpAddressTableEntry command to get the data into the arpAddressTableEntry options.

TABLE 5-99. arpServer Options

Member Usage

mode The type of ARP request handling:• Send a single ARP request to each gateway IP address for

the first IP address found in the IP address table. Results are saved in the ARP table.

• Send ARP requests using all of the addresses found in the IP address table as source addresses. ARP responses are ignored.

• Both operations.

rate ARP frame rates in frames per second.

retries Number of retries.



arpAddressTableEntry

See “arpAddressTableEntry” on page A-7 for full details.


TABLE 5-100. arpServer Sub-Commands

Member Usage

clearArpTable Clears the ARP table.

getEntry Finds the entry for a particular IP address. The data may be retrieved by calling arpAddressTableEntry.get.

getFirstEntry Positions to the first entry in the list. The data may be retrieved by calling arpAddressTableEntry.get.

getNextEntry Positions to the next entry in the list. The data may be retrieved by calling arpAddressTableEntry.get.

sendArpRequest Sends ARP requests as per the mode member.

TABLE 5-101. arpAddressTableEntry Options

Member Usage

ipAddress IP address for the entry.

macAddress MAC address for the entry



IGMP Please refer to “IGMP” on page 3-17 for a discussion of the Ixia Protocol Server’s testing model with respect to IGMP. The IGMP related commands are:

• igmpServer – configures overall operation of the Protocol Server’s IGMP operation.

• igmpAddressTable – a container used to hold the list of address table items.

• igmpAddressTableItem – an individual item for the IGMP Address Table.

These commands, and the data that they maintain are arranged in a hierarchy, as shown in Figure 5-32, “IGMP Command Hierarchy,” on page 5-50.

Figure 5-32. IGMP Command Hierarchy

igmpServer

The igmpServer object configures the overall operation of the IGMP Protocol Server. See “igmpServer” on page A-109 for full details.

The important options of this command are:TABLE 5-102. igmpServer Options

Member Usage

version Version 1 or 2 of the protocol.

sendRouterAlert Sets the IP header Send Router Alert bit.

reportMode Basic mode of response:• Report to one when queried—causes each sim-

ulated host to respond just to the specific query that it is presented with.

• Report to all when queried—causes each simu-lated host to respond with all of its memberships, regardless of the type of query that it is pre-sented with.

• Report to all unsolicited—causes each simu-lated host to automatically send full member-ships messages at regular intervals.

igmpServer

igmpAddressTable

igmpAddressTableItem



igmpAddressTable

The address table is a list of entries, each of which is described in the item com-mand. One positions within the list with the address table object and accesses ele-ments with the list object. The typical series of operations is shown in the table below:

reportFrequency When the mode is report to all unsolicited, this is the frequency in seconds with with unsolicited messages are generated.

enableQueryResponse Enables responses after initial join message.


Operation Steps

add table items 1. Set values in the igmpAddressTableItem com-mand.

2. Use the set sub-command of the igmpAddressTableItem command which transfers the data into a holding area.

3. Use the addItem sub-command of the igmpAddressTable command to move the data from the holding area to the actual list.

4. Repeat steps 1, 2 and 3 for each table item to be added.

5. Use the set sub-command of the igmpAddressTable command to send the table to the hardware.

look through table 1. Use the get sub-command of the igmpAddressTable command to transfer the data from the hardware to the object.

2. Use the get sub-command of the igmpAddressTableItem command to get the data into the ipAddressTableItem options.

3. Use the getNextItem sub-command of the igmpAddressTable command to position to the next table item.


TABLE 5-102. igmpServer Options

Member Usage



See “igmpAddressTable” on page A-105 for full details. The important sub-com-mands of this command are:


The igmpAddressTableItem is used in concert with the igmpAddressTable command. This command holds an individual table item; igmpAddressTable takes care of keeping the actual list of address table items. See “ipAddressTable-Item” on page A-120 for full details. The important options of this command are:

TABLE 5-104. igmpAddressTable Sub-Commands

Member Usage

clear Clear the IGMP address table.

addItem Adds the table item as set by the last call to igmpAddressTableItem.set to the table at the current table position.

delItem Deletes the address table item at the current position.

getFirstItem Positions to the first table item.

getNextItem Moves to the next table item.

TABLE 5-105. igmpAddressTableItem Options

Member Usage

fromClientAddresstoClientAddress

The client address range. toClientAddress is read-only.

fromGroupAddresstoGroupAddress

The group address range. toGroupAddress is read-only.

numClientAddresses The number of consecutive client addresses.

numGroupAddresses The number of consecutive group addresses.



BGP4 Please refer to “BGP4” on page 3-19 for a discussion of the Ixia Protocol Server’s testing model with respect to BGP4. The BGP4 related commands are:

• bgp4Server – provides access to the BGP4 part of a port’s protocol server.

• bgp4InternalTable / bgp4ExternalTable – a container used to hold the list of neighbor routers in the form of bgp4InternalNeighborItem / bgp4ExternalNeighborItem items. Internal and external routers are sepa-rated into different tables.

• bgp4InternalNeighborItem / bgp4ExternalNeighborItem – a container used to hold the list of route ranges in the form of bgp4RouteItem items.

• bgp4RouteItem – an individual route range and associated route attributes. More complex list based attributes are held in a list of bpg4AsPathItem items.

• bpg4AsPathItem – represents list based route attributes, including AS Set and AS Sequence.

• bgp4StatsQuery – provides access to a large number of BGP4 related sta-tistics.

These commands, and the data that they maintain are arranged in a hierarchy, as shown in Figure 5-33, “BGP4 Command Hierarchy,” on page 5-53.

Figure 5-33. BGP4 Command Hierarchy

bgp4Server

The bgp4Server command is necessary in order to access the BGP4 component of the Protocol Server for a particular port. The select sub-command must be used before all others in this category. For example, bgp4server select 1 3 4

will access the BGP4 server for chassis 1, card 3, port 4. Once a BGP4 simulation has been set up with the other commands in this section, streams can be automat-

bgp4Server

bgp4InternalTable

bgp4External

Table

bgp4Internal

NeighborItem

bgp4ExternalNeighbor

Item

bgp4RouteItem

bgp4AsPath

Item



ically generated which sends traffic to all IP addresses in all defined route ranges. This is done through the use of the generateStreams sub-command.

bgp4InternalTable / bgp4ExternalTable

The bgp4InternalTable / bgp4ExternalTable holds all entries for the simulated internal/external neighbor routers. Separate lists are kept for simulated internal versus external routers. Items are added to this table from the bgp4InternalNeighborItem / bgp4ExternalNeighborItem command; these com-mands are used in conjunction with the Table commands to build the neighbor router lists. The important options and sub-commands of this command are:

bgp4InternalNeighborItem / bgp4ExternalNeighborItem

The bgpInternalNeighborItem / bgpExternalNeighborItem holds information about a range of neighbor (routers). Bgp4RouteItems are added to the Neighbor with the addRouteItem command until all routItems are added, then bgp4InternalNeighborItems / bgp4ExternalNeighborItems are added to the bgp4InternalNeighborTable / bgp4ExternalNeighborTable with the addInternal-

TABLE 5-106. bgp4InternalTable / bgp4ExternalTable Options

Member Usage

localASNum (Internal Neighbors) The Autonomous System number associated with the routers participating in the Internal BGP (IBGP) group.

retryDelay When retries are necessary, the delay between retries.

retries The number of times to attempt an OPEN connection with the DUT router(s) before giving up.

enableActiveConnect Causes a HELLO message to be actively sent when BGP testing starts.

TABLE 5-107. bgp4InternalTable / bgp4ExternalTable Sub-Commands

Member Usage

clear Removes all neighbors from the table.

addNeighborItem Adds a neighbor to the table. The neighbor must have been previously been configured through the use of the bgpInternalNeighborItem / bgpExternalNeighborItem command.

getFirstItemgetNextItem

Allows iterative access to all the table items. Each accessed item is available via the bgpInternalNeighborItem / bgpExternalNeighborItem command.

delNeighborItem The currently accessed item (via getFirstItem and getNextItem) is deleted.



Neighbor / addExternalNeighbor command. The important options and sub-com-mands of this command are:

bgp4RouteItem

The bgp4RouteItem holds a route range that is associated with a bgp4InternalNeighborItem / bgp4ExternalNeighborItem. This command defines a set of routes and associated attributes. One attribute is supplied by a subsidiary command: bgp4ASPathItem, whose elements are included as a list associated

TABLE 5-108. bgp4InternalNeighborItem / bgp4ExternalNeighborItem Options

Member Usage

localIpAddressrangeCount

The first IP address for the simulated neighbor routers and the number of routers.

neighborASNum (External only) The first AS Num assigned to the simulated router.

asNumMode (External only) Indicates that each new session uses a different AS number.

dutIPAddress The IP address of the DUT router.

keepAliveTime The period of time between KEEP-ALIVE messages sent to the DUT.

messageTime The frequency with which UPDATE messages are sent to the DUT.

enableLinkFlaplinkFlapTImelinkFlapDropTime

Controls flapping of the link between the simulated routers and the DUT, including the period and down time.

enableStaggeredStartstaggeredStartPeriod

Controls the staggering and period of initial start messages.

TABLE 5-109. bgp4InternalNeighborItem / bgp4ExternalNeighborItem Sub-Commands

Member Usage

clearRouteList Clears the route items associated with the table item.

addRouteItem Adds a route item to the table item. The route item must have been previously been configured through the use of the bgpRouteItem command.

getRouteItemgetFirstRouteItemgetNextRouteItem

Allows direct or iterative access to all the route items. Each accessed item is available via the bgpRouteItem command.

delRouteItem Deletes the currently accessed route item.



with bgp4RouteItem. The important options and sub-commands of this command are:

TABLE 5-110. bgp4RouteItem Options


Route Ranges networkAddressfromPrefixthruPrefixnumRoutesfromPackingthruPackingiterationStepenableGenerateUniqueRoutes

Controls the range and number of network prefix addresses generated as well as how many are packed in each UPDATE message.

Flapping enableRouteFlaprouteFlapTimerouteFlapDropTimeflapFromflapTo

Enables and controls the flapping of routes to the DUT.

Next Hop enableNextHopnextHopIpAddressnextHopMode

Enables the generation of NEXT HOP attribute.

Origin enableOriginoriginProtocol

Enables the generation of the ORIGIN attribute

Local Preference

enableLocalPreflocalPref

Enables the generation of the LOCAL PREF attribute.

Multi-Exit Discriminator

enableMEDMED

Enables the generation of the MULTI-EXIT DISCRIMINATOR attribute.

Communities enableCommunitycommunityList

Enables the generation of a community list and specifies the contents of that list.

Aggregator enableAtomicAggregateenableAggregatoraggregatorIPAddressaggregatorASNumaggregatorIDMode

Enables the generation of attributes related to route aggregation: the ATOMIC AGGREGATOR and AGGREGATOR attributes.

Originator enableOriginatorIdoriginatorId

Enables the generation of the ORIGINATOR attribute.

Clusters enableClusterclusterList

Enables the generation of a cluster list and specifies the contents of that list.

AS Path enableASPathasPathSetMode

Enables the use of the AS Path attribute and its contents.



bpg4AsPathItem

The bgp4AsPathItem is used to construct AS list related items. These items must be added to a route item through the use of the bgp4RouteItem addASPath item command. The important options of this command are:

bgp4StatsQuery

The bgp4StatsQuery command is used to fetch statistics about a BGP4 session, either while it is running or afterwards. Because of the large number of statistics and the large amount of data that might be generated, this command provides the means to limit the statistics to a set of statistics for a particular pairs of neighbor routers. The important options and sub-commands of this command are:

TABLE 5-111. bgp4RouteItem Sub-Commands

Member Usage

clearASPathItem Clears the AS Path list associated with the route item.

addASPathItem Adds an AS path item to the route item. The AS path item must have been previously been configured through the use of the bgpAsPathItem command.

getASPathItemgetFirstASPathItemgetNextASPathItem

Allows direct or iterative access to all the AS Path items. Each accessed item is available via the bgpAsPathItem command.

TABLE 5-112. bgp4AsPathItem Options

Member Usage

enableAsSegment Indicates that this particular list is enabled.

asList The list of AS numbers.

asSegmentType The type of AS list in the item.

TABLE 5-113. bgp4StatsQuery Options

Member Usage

statName The name of the statistics retrieved

statValue The value of the statistic.

TABLE 5-114. bgp4StatsQuery Sub-Commands

Member Usage

addNeighbordelNeighborclearAllNeighbors

Sets up the neighbor pairs to monitor.

addStatdelStatclearAllStats

Sets up the statistics to monitor

getStat Fetches a particular statistics into the options.



OSPF Please refer to “OSPF” on page 3-17 for a discussion of the Ixia Protocol Server’s testing model with respect to OSPF. The OSPF related commands are:

• ospfServer – provides access to the OSPF part of a port’s protocol server.

• ospfRouter – a container used to hold three lists associate with the router: route ranges, interfaces and Link State Advertisements (LSA).

• ospfRouteRange – a set of routes, to be included in ospfRouter.

• ospfInterface – a network interface, to be included in ospfRouter.

• ospfUserLSAGroup – a list of LSAs, to be included in ospfRouter.

• ospfUserLSA – a single LSA description, to be included in ospfUserLSA-Group. For Router LSA entries, this command holds a list of such entries.

• ospfRouterLSAInterface – a single Router LSA Interface entry, to be included in ospfUserLSA.

These commands, and the data that they maintain are arranged in a hierarchy, as shown in Figure 5-34, “OSPF Command Hierarchy,” on page 5-58.

Figure 5-34. OSPF Command Hierarchy

ospfServer

Refer to “ospfServer” on page A-166 for a complete description of this com-mand. The ospfServer command is necessary in order to access the OSPF compo-nent of the Protocol Server for a particular port. The select sub-command must be used before all others in this category. For example, ospfserver select 1 5 2

will access the OSPF server for chassis 1, card 5, port 2.

ospfServer

ospfRouter

ospfRouteRange ospfInterface ospfUserLsaGroup

ospfUserLsa

ospfRouterLsaInterface



This command holds a list of the simulated routers. The definition of these routes occurs using the ospfROuter command and subsidiary commands. The important sub-commands of this command are:

ospfRouter

The ospfRouter command represents a simulated router. In addition to some identifying options, it holds three lists for the router:

• Route ranges – routes to be advertised by the simulated router, constructed in the ospfRouteRange command.

• Interfaces – router interface, constructed in the ospfInterface command.

• LSA Groups – Link State Advertising Groups which will be associated with advertised routes, constructed in the ospfUserLSAGroup command and subsidiary commands.The important options and sub-commands of this command shown in Table 5-116 on page 5-60.

TABLE 5-115. ospfServer Sub-Commands

Member Usage

select Selects the chassis, card and port to operate on.

clearAllRouters Removes all routers from the list of routers.

addRouter Adds a router to the list of routers. The router must have been previously been configured through the use of the ospfRouter command.

getRoutergetFirstRoutergetNextRouter

Accesses a particular router from the list, either directly by ID or by iterating through all of the routers. The data appears in the ospfRouter command.

delRouter Deletes a particular router from the list.

setRouter It is possible to change OSPF router configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the router’s configuration with ospfRouter.

(ospfRouter has capabilities for modifying elements of underlying objects as well).

2. Use the ospfServer setRouter command to set the values from ospfRouter into IxHal.

3. Use the ospfServer write command to write the changes to the hardware.

generateStreams Once an OSPF simulation has been set up with the other commands in this section, this sub-command automatically generates traffic to all IP addresses in all defined route ranges.



TABLE 5-116. ospfRouter Options

Member Usage

enable Enables or disables the simulated router.

routerId The ID of the simulated router, expressed as an IP address.

TABLE 5-117. ospfRouter Sub-Commands


Route Ranges

clearAllRouteRanges Clears all route ranges.

addRouteRange Adds a new route range. The route range must have been previously been configured through the use of the ospfRouteRange command.

getRouteRangegetFirstRouteRangegetNextRouteRange

Accesses a particular route range either by ID, or by iterating through all of the route ranges. The data appears in the ospfRouteRange command.

delRouteRange Deletes a particular route range.

setRouteRange It is possible to change route range configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the route range’s configuration

with ospfRouteRange.2. Use the ospfRouter setRouteRange

command to set the values from ospfRouteRange into IxHal.


Interfaces clearAllInterface Clears all interfaces.

addInterface Adds a new interface. The interface must have been previously been configured through the use of the ospfInterface command.

delInterface Deletes a particular interface.

getInterfacegetFirstInterfacegetNextInterface

Accesses a particular interface either by ID or by iterating through all of the interfaces. The data appears in the ospfInterface command.



ospfRouteRange

The ospfRouteRange command describes an individual set of routes. Route ranges are added into ospfRouter lists using the ospfRouter addRouteRange com-mand. The important options of this command are:

setInterface It is possible to change interface configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the interface’s configuration

with ospfInterface.2. Use the ospfRouter setInterface

command to set the values from ospfInterface into IxHal.


User LSA Group

clearAllUserLsaGroup Deletes a particular user LSA group.

addUserLsaGroup Clears all user LSA group.

delUserLsaGroup Adds a new user LSA group. The interface must have been previously been configured through the use of the ospfUserLsaGroup command.

getUserLsaGroupgetFirstUserLsaGroupgetNextUserLsaGroup

Accesses a particular user LSA group either by ID or by iterating through all of the LSA groups. The data appears in the ospfUserLsaGroup command.

setUserLsaGroup It is possible to change user LSA group configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the LSA’s configuration with

ospfUserLsaGroup.2. Use the ospfRouter setUserLsaGroup

command to set the values from ospfInterface into IxHal.


TABLE 5-118. ospfRouteRange Options

Member Usage

enable Enables the use of this route range for the simulated router.

networkIpAddress The IP address of the routes to be advertised.

TABLE 5-117. ospfRouter Sub-Commands




ospfInterface

Refer to the “ospfInterface” on page A-156 for a full description of this com-mand. The ospfInterface holds the information related to a single interface on the simulated router. Interfaces are added into the ospfRouter interface list using the ospfRouter addInterface command. In addition, learned LSAs from the DUT are made available through this command. The important options and sub-com-mands of this command are:

prefix The number of bits in the prefixes to be advertised. For example, a value of 24 is equivalent to a network mask of 255.255.255.0.

numberOfNetworks The number of prefixes to be advertised.

metric The cost metric associated with the route.

routeOrigin Whether the route originated within the area or externally.

TABLE 5-119. ospfInterface Options

Class Member Usage

Basic enable Enables the use of the simulated interface.

connectToDut Indicates that this interface is directly connected to the DUT.

ipAddress The IP address of the interface.

ipMask The IP mask associated with the interface.

OSPF Basic areaId The OSPF area ID associated with the interface.

priority The priority of the interface, for use in election of the designated or backup master.

metric The metric associated with the interface.

options Options related to the interface. Multiple options may be or’d together.-

enableValidateMtu

Enables the validation of maximum transfer units with peers

mtuSize The advertised MTU size

networkType The type of network attached to the link:• Point to point network• Broadcast network

TABLE 5-118. ospfRouteRange Options

Member Usage



linkType The type of link advertised in router LSAs, one of:• Point to point network• Transit network• Stub network

neighborRouterId If the linkType is a point to point network, this is the address of the other end of the link

Hello Interval helloInterval The time between HELLO messages sent over the interface.

deadInterval The time after which the DUT router is considered dead if it does not send HELLO messages.

Traffic Engineering

enableTrafficEngineering

Enables the generation of the Traffic Engineering opaque LSA with the remainder of the options in this class.

linkMetric The traffic engineering metric of the interface

maxBandwidth The maximum bandwidth that can be used on the link

maxReservableBandwidth

The maximum bandwidth that can be reserved on the link

unreservedBandwidthPriority0-7

The amount of bandwidth not yet reserved at each of the eight priority levels

Learned LSAs numberLearnedLsas

The number of obtained LSAs. ospfInterface getLearnedLsaList must be called first

TABLE 5-120. ospfInterface Sub-Commands

Member Usage

requestLearnedLsa The first step in obtaining the learned LSA list. It sends a request to the hardware.

getLearnedLsaList The second step in obtaining the learned LSA list. It allows the Tcl program to wait until the values are available

getFirstLearnedLsa The third step in obtaining the learned LSA list. It reads back the first learned LSA, whose values may be read through the ospfUserLsa command.

getNextLearnedLsa The fourth step in obtaining the learned LSA list. It reads back the next learned LSA, whose values may be read through the ospfUserLsa command. It should be used multiple times to obtain the whole list.

TABLE 5-119. ospfInterface Options

Class Member Usage



ospfUserLSAGroup

Refer to“ospfUserLsaGroup” on page A-176 for a full description of this com-mand. The ospfUserLSAGroup describes a list of LSAs to be associated with advertised routes. The list consists of elements constructed through the use of the ospfUserLsa command. The important options and sub-commands of this com-mand are:

ospfUserLSA

Refer to“ospfUserLsa” on page A-171 for a full description of this command. The ospfUserLSA describes an individual LSA. The types supported are:

• Route LSA – describes all of the router’s interfaces along with state and cost. This consists of a list of ospfRouterLSAInterface elements added via the ospfUserLSA addInterfaceDescriptionToRouterLsa command.

• Network LSA – generated by a designated router and lists all attached routers.

• Summary IP LSA – describes destinations outside of an area.

• Summary ASBR LSA – generated by AS Border Routers and list the ASBR itself.

• Opaque LSAs – holds information used by other protocols. Three types of LSAs are defined to indicate the scope of flooding to be performed: Local indicates that the LSA is to be flooded only within the local (sub)network, Area indicates that the LSA is to be flooded only within the associated area and Domain indicates that the LSA is to be flooded throughout the AS.

The options available cover all of the possible LSAs that are held by this com-mand. See the command description in “ospfUserLsa” on page A-171 for the

TABLE 5-121. ospfUserLSAGroup Options

Member Usage

enable Enables the use of the LSA group.

areaId The area ID for the LSA group.

TABLE 5-122. ospfUserLSAGroup Sub-Commands

Member Usage

clearAllUserLsas Clears all LSAs in the list.

addUserLsa Adds a new user LSA. The user LSA must have been previously been configured through the use of the ospfUserLSA command.

getUserLsagetFirstUserLsagetNextUserLsa

Accesses a particular user LSA by ID or by iterating through all of the user LSAs. The data appears in the ospfUserLSA command.

delUserLsa Deletes a particular user LSA.



details of which options go with each LSA. The important sub-commands of this command related to Router LSAs only, they are:

ospfRouterLSAInterface

Refer to“ospfRouterLsaInterface” on page A-164 for a full description of this command.The ospfRouterLSAInterface command describes a single Router LSA interface entry. The data from this entry is added to an ospfUserLsa list for a Router LSA entry using the ospfUserLsa addInterfaceDescriptionToRouterLsa com-mand. The options available cover the attributes of a Router LSA entry. See the command description in Appendix A for the details of which options go with each LSA. No special sub-commands are associated with this command.

TABLE 5-123. ospfUserLSA Sub-Commands

Member Usage

clearInterfaceDescription Clears all router interface descriptions LSAs in the list.

addInterfaceDescriptionToRouterLsa

Adds a new router LSA. The router LSA must have been previously been configured through the use of the ospfRouterLSAInterface command.

getFirstInterfaceDescriptiongetNextInterfaceDescription

Accesses a particular router LSA by ID or by iterating through the descriptions. The data appears in the ospfRouterLSAInterface command.

delInterfaceDescription Deletes a particular router LSA.



IS-IS Please refer to “IS-IS” on page 3-24 for a discussion of the Ixia Protocol Server’s testing model with respect to IS-IS. The IS-IS related commands are:

• isisServer – provides access to the IS-IS part of a port’s protocol server.

• isisRouter – a container used to hold two lists associate with the router: route ranges and interfaces.

• isisRouteRange – a set of routes, to be included in isisRouter.

• isisInterface – a network interface, to be included in isisRouter.

These commands, and the data that they maintain are arranged in a hierarchy, as shown in Figure 5-35, “ISIS Command Hierarchy,” on page 5-66.

Figure 5-35. ISIS Command Hierarchy

isisServer

Refer to“isisServer” on page A-134 for a full description of this command. The isisServer command is necessary in order to access the ISIS component of the Protocol Server for a particular port. The select sub-command must be used before all others in this category. For example, isisServer select 1 5 2

will access the IS-IS server for chassis 1, card 5, port 2.

This command holds a list of the simulated routers. The definition of these routes occurs using the isisRouter command and subsidiary commands. The important sub-commands of this command are shown in Table 5-124 on page 5-66.

TABLE 5-124. isisServer Sub-Commands

Member Usage


clearAllRouters Removes all routers from the list of routers.

addRouter Adds a router to the list of routers. The router must have been previously been configured through the use of the isisRouter command.


Accesses a particular router from the list, either directly by ID or by iterating through all of the routers. The data appears in the isisRouter command.

isisServer

isisRouter

isisRouteRange isisInterface



isisRouter

Refer to“isisRouter” on page A-130 for a full description of this command. The isisRouter command represents a simulated router. In addition to some identify-ing options, it holds two lists for the router:

• Route ranges – routes to be advertised by the simulated router, constructed in the isisRouteRange command.

• Interfaces – router interface, constructed in the isisInterface command.

The important options and sub-commands of this command are shown in Table 5-125 on page 5-67.


setRouter It is possible to change ISIS router configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the router’s configuration with isisRouter.

(isisRouter has capabilities for modifying elements of underlying objects as well).

2. Use the isisServer setRouter command to set the values from isisRouter into IxHal.

3. Use the isisServer write command to write the changes to the hardware.

generateStreams Once an OSPF simulation has been set up with the other commands in this section, this sub-command automatically generates traffic to all IP addresses in all defined route ranges.

TABLE 5-125. isisRouter Options

Member Usage

enable Enables or disables the simulated router.

routerId The ID of the simulated router, expressed as an IP address.

maxNumberOfAddresses The Number of Area Addresses permitted for this IS area.

areaAddressList The list of area addresses to use.

TABLE 5-124. isisServer Sub-Commands

Member Usage



TABLE 5-126. isisRouter Sub-Commands


Route Ranges

clearAllRouteRanges Clears all route ranges.

addRouteRange Adds a new route range. The route range must have been previously been configured through the use of the isisRouteRange command.


Accesses a particular route range either by ID, or by iterating through all of the route ranges. The data appears in the isisRouteRange command.


setRouteRange It is possible to change route range configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the interface’s configuration

with isisRouteRange.2. Use the isisRouter setRouteRange

command to set the values from isisRouteRange into IxHal.


Interfaces clearAllInterface Clears all interfaces.

addInterface Adds a new interface. The interface must have been previously been configured through the use of the isisInterface command.

delInterface Deletes a particular interface.

getInterfacegetFirstInterfacegetNextInterface

Accesses a particular interface either by ID or by iterating through all of the interfaces. The data appears in the isisInterface command.

setInterface It is possible to change interface configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the interface’s configuration

with isisInterface.2. Use the isisRouter setInterface

command to set the values from isisInterface into IxHal.




isisRouteRange

Refer to“isisRouteRange” on page A-133 for a full description of this command. The isisRouteRange command describes an individual set of routes. Route ranges are added into isisRouter lists using the isisRouter addRouteRange command. The important options of this command are:

isisInterface

Refer to“isisInterface” on page A-128 for a full description of this command. The isisInterface holds the information related to a single interface on the simu-lated router. Interfaces are added into the isisRouter interface list using the isis-Router addInterface command. The important options of this command are:

TABLE 5-127. isisRouteRange Options

Member Usage


networkIpAddress The IP address of the routes to be advertised.

prefix The number of bits in the prefixes to be advertised. For example, a value of 24 is equivalent to a network mask of 255.255.255.0.

numberOfNetworks The number of prefixes to be advertised.


TABLE 5-128. isisInterface Options

Member Usage


connectToDut If set, this IS-IS interface is directly connected to the DUT.

networkType Indicates the type of network attached to the interface: broadcast or point-to-point.

ipAddress The IP address for this interface.

ipMask The IP mask associated with the IP address for this interface.


level The IS-IS level associated with the interface: level 1, 2 or both.

interfaceId The OSI interface ID for this interface.

priorityLevel1priorityLevel2

The priority level associated with the Level 1 or Level 2 aspect of the interface. This is used in master election.



helloIntervalLevel1helloIntervalLevel2

The hello interval used with the Level 1 or Level 2 aspect of the interface. Used to send regular messages to neighbor IS-IS routers.

deadIntervalLevel1dealIntervalLevel2

The dead interval used with the Level 1 or Level 2 aspect of the interface. Used to determine if neighbor routers are non-operational.

TABLE 5-128. isisInterface Options

Member Usage



RSVP-TE Please refer to “RSVP-TE” on page 3-27 for a discussion of the Ixia Protocol Server’s testing model with respect to RSVP. The RSVP related commands are:

• rsvpServer – provides access to the RSVP part of a port’s protocol server.

• rsvpNeighborPair – describes a pair of routers in which one is the DUT and the other is simulated by the Ixia port.

• rsvpDestinationRange – describes a set of routers which are the destination of MPLS tunnels. Destination ranges correspond to Ingress or Egress rout-ers.

• rsvpSenderRange – describes a set of routers which are the source of MPLS tunnels in an Ingress simulation.

• rsvpEroItem – describes an Explicit Route Item entry for use in Ingress router simulations.

• rsvpRroItem – describes an Return Route Item entry for use in Egress router simulations.

These commands, and the data that they maintain are arranged in a hierarchy, as shown in Figure 5-36, “RSVP Command Hierarchy,” on page 5-71.

Figure 5-36. RSVP Command Hierarchy

rsvpServer

Refer to“rsvpServer” on page A-248 for a full description of this command. The rsvpServer command is necessary in order to access the RSVP component of the Protocol Server for a particular port. The select sub-command must be used before all others in this category. For example, rsvpServer select 1 5 2

will access the RSVP server for chassis 1, card 5, port 2.

This command holds a list of adjacent routers, called neighbor pairs. The defini-tion of these routers occurs using the rsvpNeighborPair command and subsidiary commands. The important sub-commands of this command are shown in Table 5-129 on page 5-72.

rsvpServer

rsvpNeighborPair

rsvpSenderRange rsvpRroItem

rsvpDestinationRange

rsvpEroItem



rsvpNeighborPair

Refer to“rsvpNeighborPair” on page A-241 for a full description of this com-mand. The rsvpNeighborPair command represents a pair of routers – one is the DUT and the other is simulated by the Ixia Protocol Server. In addition to some identifying options, it holds a list for the router:

• Destination Ranges – a list of routers which represent the termination point of MPLS tunnels being constructed. Destination ranges are constructed in the rsvpRouteRange command.

TABLE 5-129. rsvpServer Sub-Commands

Member Usage


clearAllNeighborPair Removes all Neighbor Pairs from the list of Neighbor Pairs.

addNeighborPair Adds a NeighborPair to the list of Neighbor Pairs. The Neighbor Pair must have been previously been configured through the use of the rsvpNeighborPair command.

getNeighborPairgetFirstNeighborPairgetNextNeighborPair

Accesses a particular Neighbor Pair from the list, either directly by ID or by iterating through all of the Neighbor Pairs. The data appears in the rsvpNeighborPair command.

delNeighborPair Deletes a particular NeighborPair from the list.

setNeighborPair It is possible to change RSVP neighbor pair configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the neighbor pair’s configuration with

rsvpNeighborPair. (rsvpNeighborPair has capabilities for modifying elements of underlying objects as well).

2. Use the rsvpServer setNeighborPair command to set the values from rsvpNeighborPair into IxHal.

3. Use the rsvpServer write command to write the changes to the hardware.

generateStreams Once an RSVP simulation has been set up with the other commands in this section, has been started and has run long enough to receive labels from the DUT, this sub-command automatically generates traffic. Traffic is generated for each label received from the DUT. Traffic is sent from the first address in the sender range to the first address in the destination range for the neighbor pair associated with the label.




TABLE 5-130. rsvpNeighborPair Options


Neighbor Pair enableNeighborPair Enables or disables the simulated neighbor pair.

ipAddress The IP address of the simulated router

dutAddress The IP address of the Device Under Test. This is the RSVP router that the simulated router is directly connected to.

Hello Messages enableHello Enables the transmission of HELLO messages between the simulated router and the DUT.

helloInterval The interval, in seconds, between HELLO messages.

helloTimeoutMultplier The number of Hellos sent without confirmation before the DUT is considered dead.

Label Space labelSpaceStart The first label to be used for RSVP tunnels.

labelSpaceEnd The last label to be used for RSVP tunnels.

Returned Labels lsp_tunnel When received MPLS labels are retrieved from the Protocol Server for the simulated server, this represents the tunnel ID for the returned label.

rxLabel This is the MPLS label associated with the tunnel ID in lsp_tunnel.

numRxLabels The number of received labels

TABLE 5-131. rsvpRouter Sub-Commands


Destination Ranges

clearAllDestinationRange Clears all destination ranges associated with the neighbor pair.

addDestinationRange Adds a new destination range. The destination range must have been previously been configured through the use of the rsvpDestinationRange command.




Refer to“rsvpDestinationRange” on page A-235 for a full description of this command. The rsvpDestinationRange command describes a set of MPLS routers which are the tunnel endpoints for a number of MPLS tunnels established with RSVP. Three other lists are associated with this command:

• rsvpSenderRange–a set of MPLS routers which are the tunnel start-points.

• rsvpEroItem–a set of addresses associated with the Explicit Route Option of RSVP messages. This option indicates the path through a set of MPLS routers that the tunnel is to take. This is used when the destination range is associated with an Ingress router.

• rsvpRroItem–a set of addresses associated with the Returned Route Option. This option indicates the set of MPLS routers that were used in a tunnel’s creation. This is used when the destination range is associated with an Egress router.

getDestinationRangegetFirstDestinationRangegetNextDestinationRange

Accesses a particular destination range either by ID, or by iterating through all of the destination ranges. The data appears in the rsvpDestinationRange command.

delDestinationRange Deletes a particular destination range.

Received Labels

requestRxLabels This is the first step in retrieving labels from the DUT. This sub-command requests that all of the received MPLS tunnel-label pairs be retrieved.

getLabels This is the second step in retrieving labels from the DUT. This sub-command allows the Tcl program to wait until the labels have been retrieved.

getFirstLabelgetNextLabel

This is the last step in retrieving labels from the DUT. These sub-commands gets the first and subsequent received tunnel-label pair from the list retrieved with requestRxLabels. The values are available in the numRxLabels, lsp_tunnel and rxLabel options.

TABLE 5-131. rsvpRouter Sub-Commands





TABLE 5-132. rsvpDestinationRange Options


DestinationRange enableDestinationRange

Enables or disables the use of the destination range.

behavior Indicates whether the destination range corresponds to an Ingress or Egress router.

fromIpAddress The IP address of the first destination router.

rangeCount The number of destination routers. Each router’s address is one greater than the previous one’s.

tunnelIdStart Sets the start of the range of Tunnel IDs to be used in simulations.

tunnelIdEnd The end of the range of Tunnel IDs.

ERO enableEro Enables use of the ERO option in Ingress mode.

eroMode Indicates whether the DUT’s address is to be prepended to the ERO list and whether it is a LOOSE or STRICT entry.

prefixLength If the DUT’s address is to be prepended to the ERO list, this indicates what prefix length is to be used for the entry.

Ingress Options enableSendRro When the destination range is used in Ingress mode, this indicates that a SEND RRO option is to be included in RSVP messages sent downstream.

Egress Options refreshInterval When the destination range is used in Egress mode, this indicates the time, in seconds, between the simulated router’s message to the DUT.

bandwidth The requested bandwidth for the tunnel, expressed in kbits per second.

timeoutMultiplier The number of Hellos before a router is declared dead.

enableResvConf Indicates whether RESV confirmation messages are to generated in response to RESV messages with the RESV confirmation class object.



TABLE 5-133. rsvpDestinationRange Sub-Commands


Sender Ranges clearAllSender Clears all sender ranges.

addSenderRange Adds a new sender range. The sender range must have been previously been configured through the use of the rsvpSenderRange command.

getSenderRangegetFirstSenderRangegetNextSenderRange

Accesses a particular sender range either by ID, or by iterating through all of the Sender ranges. The data appears in the rsvpSenderRange command.

delSenderRange Deletes a particular sender range.

setSenderRange It is possible to change sender range configuration ‘on the fly’. In order to do this, the following steps are necessary:1. Modify the sender range’s

configuration with rsvpSenderRange.

2. Use the rsvpDestinationRange setSenderRange command to set the values from rsvpSenderRange into IxHal.

3. Use the rsvpServer write command to write the changes to the hardware.

ERO Items clearAllEro Clears all ERO list items.

addEroItem Adds a new ERO item. The ERO item must have been previously been configured through the use of the rsvpEroItem command.

getFirstEroItemgetNextEroItem

Accesses a particular sender range by iterating through all of the Sender ranges. The data appears in the rsvpEroItem command.

RRO Items clearAllRro Clears all RRO list items.



rsvpSenderRange

Refer to“rsvpSenderRange” on page A-246 for a full description of this com-mand. The rsvpSenderRange holds the information related to the originating routers for the MPLS tunnels being simulated in Ingress cases. Sender ranges are added into the rsvpDestinationRanges list using the rsvpDestinationRanges addSenderRange command. The important options of this command are:

addRroItem Adds a new RRO item. The RRO item must have been previously been configured through the use of the rsvpRroItem command.

getFirstRroItemgetNextRroItem

Accesses a particular sender range by iterating through all of the Sender ranges. The data appears in the rsvpRroItem command.

TABLE 5-134. rsvpSenderRange Options


Sender Range

enableSenderRange Enables the sender range entry.

fromIpAddress The IP address of the first sender router.

rangeCount The number of routers in the sender range. Each sender router has an IP address one higher than its predecessor.

lspIdStart The start of the range of LSP IDs to be generated.

lspIdEnd The end of the range of LSP IDs.

General Options

refreshInterval The value of the refresh interval, in milliseconds.

bandwidth The bandwidth requested for the connection, expressed in kbits/sec.

timeoutMultiplier The number of Hellos before a neighbor is declared dead.

Session Attributes

enableAutoSessionName

Enables the Session Name to be generated automatically.

sessionName If enableAutoSessionName is not set, this is the name assigned to this Session.

TABLE 5-133. rsvpDestinationRange Sub-Commands




rsvpEroItem

Refer to“rsvpEroItem” on page A-239 for a full description of this command. The rsvpEroItem holds the information related to an ERO item used for in Ingress mode. ERO items are added into the rsvpDestinationRange list using the

setupPriority This is the session priority with respect to taking resources, such as preempting another session. The valid range is from 0 to 7. The highest priority is indicated by 0.

holdingPriority This is the session priority with respect to holding resources, such as keeping a session during preemption. The valid range is from 0 to 7. The highest priority is indicated by 0.

enableLocalProtectionDesired

This permits transit routers to use a local traffic rerouting repair mechanism, in the event of a fault on an adjacent downstream link or node. This may result in a violation of the explicit route object.

enableLabelRecordingDesired

This indicates that label information is to be included when doing a record route operation.

enableSeStyleDesired This indicates that the tunnel ingress node may reroute this tunnel without tearing it down. A tunnel egress node should use the SE Style when responding with an RESV message.

enableRaSessionAttribute

Enables the use of resource affinities as set by excludeAny, includeAny, and includeAll.

excludeAny Represents a set of attribute filters associated with a tunnel, any of which renders a link unacceptable.

includeAny Represents a set of attribute filters associated with a tunnel, any of which makes a link acceptable (with respect to this test). When all bits are set to 0 (null set), it automatically passes.

includeAll Represents a set of attribute filters associated with a tunnel, all of which must be present for a link to be acceptable (with respect to this test). When all bits are set to 0 (null set), it automatically passes.

TABLE 5-134. rsvpSenderRange Options




rsvpDestinationRange addEroItem command. The important options of this command are:

rsvpRroItem

Refer to“rsvpRroItem” on page A-244 for a full description of this command. The rsvpRroItem holds the information related to an RRO item used for Egress mode. RRO items are added into the rsvpDestinationRange list using the rsvp-DestinationRange addRroItem command. The important options of this com-mand are:

TABLE 5-135. rsvpEroItem Options

Member Usage

type The type of contents in the ERO entry. Either IP (IPv4 address) or AS (Autonomous System).

ipAddress If the type field is IP, then this is the ERO value as an IP address prefix.

asNumber If the type field is AS, then this is the ERO value as an Autonomous System Number.

prefixLength If the type field is IP, then this defines the prefix length of the DUT IP address.

enableLooseFlag Indicates whether the ERO item is to be considered a LOOSE item or a STRICT item.

TABLE 5-136. rsvpRroItem Options

Member Usage

type The type of contents in the RRO entry. Either IP (IPv4 address) or Label.

ipAddress If the type field is IP, then this is the RRO value as an IPv4 address.

label If the type field is Label, then this is the RRO value as an assigned label.

enableProtectionAvailable

If the type field is IP, then this indicates that local protection is made available for the downstream link.

enableProtectionInUse If the type field is IP, then this indicates that the local protection is being used currently to maintain this tunnel.

cType If the type field is IP, then this is the C_Type of the included Label Object.

enableGlobalLabel If the type field is IP, then this indicates that the label will be understood if received on any interface.



RIP The RIP related commands are:

• ripServer – provides access to the RIP part of a port’s protocol server.

• ripInterfaceRouter – a container used to hold the list of route ranges asso-ciated with the simulated router.

• ripRouteRange – a set of routes, to be included in ripInterfaceRouter.

These commands, and the data that they maintain are arranged in a hierarchy, as shown in Figure 5-37, “RIP Command Hierarchy,” on page 5-80.

Figure 5-37. RIP Command Hierarchy

ripServer

Refer to“ripServer” on page A-231 for a full description of this command. The ripServer command is necessary in order to access the RIP component of the Protocol Server for a particular port. The select sub-command must be used before all others in this category. For example, ripServer select 1 5 2

will access the RIP server for chassis 1, card 5, port 2.

This command holds a list of the simulated routers. The definition of these rout-ers occurs using the ripInterfaceRouter command and subsidiary commands. The important sub-commands of this command are shown in Table 5-137 on page 5-80.

TABLE 5-137. ripServer Sub-Commands

Member Usage


clearAllRouter Removes all routers from the list of routers.

addRouter Adds a router to the list of routers. The router must have been previously been configured through the use of the ripInterfaceRouter command.

ripServer

ripRouter

ripRouterRange



ripInterfaceRouter

The ripInterfaceRouter command represents a simulated router. In addition to some identifying options, it holds a list for the router:

• Route ranges – routes to be advertised by the simulated router, constructed in the ripRouteRange command.



Accesses a particular router from the list, either directly by ID or by iterating through all of the routers. getFirstRouter should be called before getNextRouter. The data appears in the ripInterfaceRouter command.


setRouter This command allows you to change a router’s configuration on-the-fly while the RIP protocol is running. Changes to the router’s configuration are made with the ripInterfaceRouter command. This call must be followed by a call to ripServer write.

TABLE 5-138. ripInterfaceRouter Options


Router enableRouter Enables or disables the simulated router.

ipAddress The IP address of the simulated RIP router.

ipMask The network mask associated with the ipAddress.

Operating mode responseMode The current implementation uses Split Horizon as its update mode. Split Horizon is a method for omitting routes learned from a neighbor in update messages to that same neighbor. Additional options will be offered in future releases.

sendType The method for sending RIP packets. One of:• Multicast - sends Version 2

packets via multicast.• Broadcast Ver1 - sends V1

packets via broadcast.• Broadcast Ver2 - sends V2

packets via broadcast.

TABLE 5-137. ripServer Sub-Commands

Member Usage



receiveType Filters the version of messages this router will receive. One of:• Version1 - RIP Version 1 mes-

sages only.• Version2 - RIP Version 2 mes-

sages only.• Version1+2 - Both RIP ver-

sion messages.

updateInterval The time, in seconds, between transmitted update messages.

updateIntervalOffset A random percentage of this time value, expressed in seconds, which will be added or subtracted from the update interval.

Authorization enableAuthorization Indicates whether authorization is included in update messages.

authorizationPassword If enableAuthorization is set, this is the 16-character password to be used. Only simple password authentication is supported.

TABLE 5-139. ripInterfaceRouter Sub-Commands


Route Ranges

clearAllRouteRange Clears all route ranges.

addRouteRange Adds a new route range. The route range must have been previously been configured through the use of the ripRouteRange command.


Accesses a particular route range either by ID, or by iterating through all of the route ranges. getFirstRouteRange should be called before getNextRouteRange. The data appears in the ripRouteRange command.


setRouteRange This command may be used to change an individual route range on-the-fly while the RIP protocol server is running. Changes to the route range are made with the ripRouteRange command. This command must be followed with a call to ripServer write.

TABLE 5-138. ripInterfaceRouter Options




ripRouteRange

The ripRouteRange command describes an individual set of routes. Route ranges are added into ripInterfaceRouter lists using the ripInterfaceRouter addRouteR-ange command. The important options of this command are:

TABLE 5-140. ripRouteRange Options

Member Usage

enableRouteRange Enables the use of this route range for the simulated router.

routeTag A arbitrary value associated with the routes in this range. It is used to provide a means for distinguishing internal vs. external RIP routes.

networkIpAddress The network address to be used in creating this route range.

networkMaskWidth The network mask to be applied to the networkIpAddress to yield the non-host part of the address. A value of 0 means there is no subnet address.

numberOfNetworks The number of networks to be generated for this route range, based on the network address plus the network mask.

nextHop The immediate next hop IP address on the way to the destination address.

metric The total metric cost for these routes. The valid range is from 1 to 16 (inclusive). A value of 16 means that the destination is not reachable, and that route will be removed from service.


6This chapter presents a description of the High-Level API commands organized by major topics:

• Initialization and Setup—basic overhead to set up the test and Ixia hardware.

• Port Ownership—commands to control port ownership and sharing.

• Data Transmission—setup for data transmission and control of the transmis-sion.

• Data Capture and Statistics—setup for data capture and control capture and statistics.

• Protocol Server—special treatment given to IP, ARP and IGMP.

• Console Output and Logging—output messages to the console and log files.

This chapter provides an overview of the high-level API functions and utility commands. The full details of the commands described herein may be found in the following appendices:

• Appendix B - Utility Commands includes complete descriptions of each of the Utility commands.

• Appendix C - High-Level API includes complete descriptions of each of the high-level commands.

The high-level commands are characterized by one or more characteristics:

• They perform a combination of IxTclHAL commands.

• They perform one or more IxTclHAL commands over a range of ports.

• They control test operation sequences.

Arguments to the high-level APIs are passed in one of two ways:

• By value–denoted by (By value) in the Appendix C description. By value arguments are either a constant or a $variable reference. For example:

32, {{1 1 1} {1 2 1}} or $portList

Chapter 6: High-Level and Utility API Description


High-Level and Utility API Description6

• By reference–denoted by (By reference) in the Appendix C description. By value arguments must be references to variables, without the ‘$’. For example, pl after set pl {{1 1 1} [1 1 2}} or one2oneArray.

Read the individual description pages in Appendix C to determine which argu-ments are passed by reference and by value.


High-Level and Utility API DescriptionInitialization and Setup

Initialization and SetupThe commands in this section relate to overhead operations necessary to prepare for data transmission, capture and statistical analysis. The commands covered in this section are:

• Mapping and Port Lists

• map

• ixCreatePortListWildCard

• ixCreateSortedPortList

• Including Source Code

• ixSource

• Chassis and TclServer Connection

• ixInitialize

• ixConnectToTclServer / ixDisconnectTclServer

• ixProxyConnect

• ixConnectToChassis / ixDisconnectFromChassis

• ixGetChassisID

• user

• General Purpose Commands

• ixWritePortsToHardware

• ixWriteConfigToHardware

Mapping and Port Lists

Four types of traffic mappings are common in Tcl tests, as shown in Figure 6-1 on page 6-4.

1. One-to-one mapping: one transmit port is mapped to one receive port. For example, port 1 of the Ixia chassis transmits to port 1 of the DUT, which for-wards traffic back on its port 2 to Ixia chassis port 2.

2. One-to-many mapping: one transmit port is mapped to multiple receive ports. For example, port 1 of the Ixia chassis transmits to port 1 of the DUT, which forwards back on its ports 2, 3, and 4 to Ixia chassis ports 2, 3, and 4.

3. Many-to-one mapping: multiple transmit ports mapped to a single receive port. For example, ports 1, 2, and 3 of Ixia chassis transmit to ports 1, 2, and 3 of the DUT, which forwards back on its port 4 to Ixia chassis port 4.

4. Many-to-many mapping: multiple transmit ports are mapped to multiple receive ports. For example, port 1 of the Ixia chassis transmits to port 1 of the DUT, which forwards back on its ports 2, 3, and 4 to Ixia chassis ports 2, 3, and 4; at the same time, port 2 of the Ixia chassis transmits to port 2 of the DUT which forwards back on its ports 1, 3, 4 to Ixia chassis ports 1, 3, and 4; and so on. In this mapping, all ports transmit to and receive from all other ports in the system.


High-Level and Utility API DescriptionInitialization and Setup6

The traffic mapping is a logical collection of ports and configurations stored in memory. It simplifies the identification of transmit and receive ports during the configuration of streams and filters.

Figure 6-1. Traffic Mappings

Tcl programmers will find it convenient to configure their ports using the map utility command. map builds one of four global arrays:

• one2oneArray–sets up one transmit and one receive port for traffic flow. The transmit/receive port pair that has been configured once cannot be used in a different port pair. That is, each port pair is mutually exclusive.

• one2manyArray–sets up one transmit port and multiple receive ports. Each group of transmit and its multiple receive ports is mutually exclusive with other groups.

• many2oneArray–sets up multiple transmit ports and one receive port. Each group of multiple transmit ports and its receive port is mutually exclusive with other groups.

• many2manyArray–sets up multiple transmit ports and multiple receive ports. Any port may transmit and receive to any other port in any group of ports.

Ixia Tester DUT Ixia Tester DUT

One-to-One Mapping One-to-Many Mapping

Ixia Tester DUT Ixia Tester DUT

Many-to-One Mapping Many-to-Many Mapping



map

The map command is used to define any of the four basic array types. Refer to “map” on page B-16 for full details. The important options and sub-commands of this command are:

Any of the four global arrays may be used in most of the high-level commands where a portList is called for as:

• one2oneArray

• one2manyArray

• many2oneArray

• many2manyArray

The command will use the part of the array appropriate to the command; for example, ixStartTransmit will use only the transmit ports of the array. Alter-natively, any command that calls for a portList may construct an array of ports and use it as an argument. Two alternative forms are defined:

• {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} – four ports: chassis 1, card 1, ports 1-4

• {1,1,1 1,1,2 1,1,3 1,1,4} – four ports: chassis 1, card 1, ports 1-4. Specifi-cations are separated by spaces.

ixCreatePortListWildCard

Port lists may of course be created by hand. For example:{{1 1 1} {1 1 2} {1 1 3} {1 1 4}}

The ixCreatePortListWildCard command can be used to build a sorted list containing wild card characters (*) to indicate all cards and/or all ports. For example, ixCreatePortListWildCard {{1 * *}} - all cards and all ports on chassis 1ixCreatePortListWildCard {{1 1 *} {1 2 1} {1 2 2}} - all ports on card 1 and ports 1 and 2 on card 2.

TABLE 6-1. map Options

Member Usage

type The type of mapping; one of one2one, one2many, many2one or many2many.

TABLE 6-2. map Sub-Commands

Member Usage

add Adds a new transmit port - receive port pair to the mapping.

del Deletes a transmit port - receive port pair from the mapping.

new Clears the current map and creates a new map as described in type, above.

show Shows the current map configuration.



A wild card cannot be used for chassis ID. Also, if a combination of a list ele-ment containing wild cards and port numbers are used, then the port list passed must be in a sorted order. The format of this command is:

ixCreatePortListWildCardOptions portList [excludePortList]

where portList is the list of ports (with wildcards) to be included, and excludePortList is a list of ports, which may not contain wildcards, which should be omitted from the returned list.

Refer to “ixCreatePortListWildCard” on page -24 for full details of this com-mand.

ixCreateSortedPortList

The ixCreateSortedPortList command can be used to construct a port list for a range of ports – from a port on a single card to another port on a different card. For example:ixCreateSortedPortList {1 1 1} {1 5 4} {{1 3 2}}- all ports between chassis 1 card 1 port 1 and port 4 on card 5, excluding card 3 port 2.

The format of this command is:

ixCreateSortedPortList portFrom portTo exclude

where portFrom is the first port in the range and portTo is the last port in the range. These are individual port specifications – not a list of lists as in other com-mands. exclude is a list of lists indicating individual ports to be omitted from the list; an empty list is expressed as {{}}.

Refer to “ixCreateSortedPortList” on page C-25 for full details of this com-mand.

Including Source Code

ixSource

The ixSource command is very useful in sourcing large number of .tcl files from a directory or a number of individual files. It may be called with either a single directory name or a set of full path names. In the former case, all the .tcl files within the directory are sourced and in the latter case, each of the individual files are sourced. The format of this command is:

ixSource {fileNames | directoryName}

where fileNames is any number of files to be sourced and directoryName is the directory name where all the files under that directory are going to be sourced.

Refer to “ixSource” on page C-71 for full details on this command.

Chassis and TclServer Connection

Several commands are available to initialize connection to the chassis chain to be used for testing. Provisions are included to connect to TclServer from Unix plat-forms.



ixInitialize

The ixInitialize command establishes connection with a list of chassis and will assign chassis ID numbers to the chassis in the chain. The ID numbers will be assigned in incrementing order to the master and slave chassis with the master chassis given ID 1. Also, it will open a log file for the script. This command should be the first one in the script file after the IxTclHal package is loaded using package require command. The format of this command is:

ixInitialize chassisList [cableLen [logfilename] [client]]

where chassisList is a list of all of the chassis in the chain – either IP addresses or host names that can be resolved through DNS, cableLen is the length of cables that connects the chassis, logfilename is the file to create to store log messages and client is the name of the user.

If this command is called from a Unix client, it will also connect to the TclServer running on the first chassis in the list. If the TclServer is running on a host other than the chassis, then the ixConnectToTclServer and ixConnectToChassis com-mands should be used instead. Running TclServer on an Ixia chassis can adversely affect its performance; it is recommended that TclServer be run on some other Windows machine.

Refer to “ixInitialize” on page C-36 for a full description of this command.

ixConnectToTclServer / ixDisconnectTclServer

It can be used from a Unix client to connect to a host that runs the TclServer, or disconnect from the server. The format of these command is:

ixConnectToTclServer serverName

ixDisconnectTclServer

where serverName is the hostname or IP address of the Windows based machine hosting the TCL Server.

Refer to “ixConnectToTclServer” on page C-23 and “ixDisconnectTclServer” on page C-30 for a full description of this command.

ixProxyConnect

The ixProxyConnect command combines the functions of ixTclSrvConnect and IxInitialize. The format of this command is:

ixProxyConnect chassisName chassisList [cableLen [logfilename]]

where chassisName is the hostname or IP address of a host running TclServer which will be used from Unix clients, chassisList is a list of all of the chassis in the chain - either IP addresses or host names that can be resolved through DNS, cableLen is the length of cables that connects the chassis, and logfilename is the file to create to store log messages.

Refer to “ixProxyConnect” on page C-50 for a full description of this command.



ixConnectToChassis / ixDisconnectFromChassis

The ixConnectToChassis command is called from ixInitialize. It con-nects to a list of chassis given the host names or IP addresses. The format of these commands are:

ixConnectToChassis chassisList [cableLen]

ixDisconnectFromChassis

where chassisList is a list of all of the chassis in the chain - either IP addresses or host names that can be resolved through DNS and cableLen is the length of cables that connects the chassis.

Refer to “ixConnectToChassis” on page C-21 and “ixDisconnectFromChassis” on page C-29 for a full description of these commands.

ixGetChassisID

This command obtains the chassis ID of a chassis given its hostname or IP address. This command is needed after using ixInitialize or ixProxyConnect in order to obtain automatically assigned chassis IDs. The format of the command is:

ixGetChassisID chassisName

where chassisName is the hostname or IP address of the chassis. Refer to “ixGet-ChassisID” on page C-35 for a full description of this command.

user

This command has no effect on test operation. Rather it provides a means of stor-ing global information about the user and the DUT. The only sub-commands available are config and cget. The important options of this command are:

Refer to “user” on page B-19 for a full description of this command.

TABLE 6-3. user Options

Member Usage

productname Name of the DUT being tested.

version Version number of the product.

serial# Serial number of the product.

username The name of the user running the tests.



General Purpose Commands

The following two commands are invaluable tools for committing large amounts of configuration information to the hardware.

ixWriteConfigToHardware

This command commits the configuration of streams, filters, and protocol infor-mation on a group of ports to hardware. The format of the command is:

ixWriteConfigToHardware portList

where portList is a list of ports to apply the command to. Refer to “ixWriteCon-figToHardware” on page C-133 for full description of this command.

ixWritePortsToHardware

In addition to performing all of the functions of IxWriteConfigToHardware, this command commits the configuration of ports such as Mii properties on 10/100 interface (speed, duplex modes, auto-negotiation), port properties on Gigabit interfaces, and PPP parameters on Packet over Sonet interfaces on a group of ports to hardware. Link may drop as a result of this command’s execution. The format of the command is:

ixWritePortsToHardware portList

where portList is a list of ports to apply the command to. Refer to “ixWritePorts-ToHardware” on page C-135 for full description of this command.


High-Level and Utility API DescriptionPort Ownership6

Port OwnershipPorts on chassis may be shared among a number of users. The commands in this section control user login and port sharing:

• ixLogin / ixLogout

• ixCheckOwnership

• ixPortTakeOwnership / ixTakeOwnership / ixPortClearOwnership / ixClearOwnership

ixLogin / ixLogout The ixLogin command registers a name to associate with port ownership and the ixLogout command dissociates ownership. The format of these commands are:

ixLogin ixiaUser

ixLogout

where ixiaUser is the name of the current user.

Refer to “ixLogin” on page C-46 and “ixLogout” on page C-47 for full details on these commands.

ixCheckOwnership The ixCheckOwnership command is used to check for the availability of a number of ports before taking ownership. The format of this command is:

ixCheckOwnership portList

where portList is a list of ports, which may contain wildcards. The ixCheckOwn-ership command requires that the list be passed by value. For example,set p1 {{1 1 1} {1 1 2}}ixCheckOwnership $p1

A value of 0 is returned if all of the ports are available. Refer to “ixCheckOwner-ship” on page C-4 for a full description of this command.

ixPortTakeOwnership / ixTakeOwnership / ixPortClearOwnership / ixClearOwnership

The ixPortTakeOwnership and ixTakeOwnership commands take owner-ship of a single port or list of ports, respectively. The ixPortClearOwnership and ixClearOwnership commands give the ports back. The format of these command are:

ixPortTakeOwnership chassisID cardID portID [takeType]

ixTakeOwnership portList [takeType]

ixPortClearOwnership chassisID cardID portID [takeType]

ixClearOwnership [portList [takeType]]

where chassisID, cardID and portID define an individual port, portList is a list of ports and takeType may be force in order to force the taking or release of owner-ship regardless of ownership by another user. The port list must be passed by


High-Level and Utility API DescriptionPort Ownership

value as in the ixCheckOwnership command. A call to ixClearOwnership without any arguments will clear all ports owned by the currently logged on user.

Refer to “ixPortTakeOwnership” on page C-49, “ixTakeOwnership” on page C-123, “ixPortClearOwnership” on page C-48 and “ixClearOwnership” on page C-12 for complete descriptions of these commands.


High-Level and Utility API DescriptionData Transmission6

Data TransmissionThe data transmission commands relate the preparation for or the transmission of data to the DUT. Several utility commands, which calculate frequently used val-ues, are detailed as well. The commands covered are:

• Setup

• ixCheckLinkState

• ixCheckPPPState

• ixSetPortPacketFlowMode / ixSetPacketFlowMode

• ixSetPortPacketStreamMode / ixSetPacketStreamMode

• ixSetPortTcpRoundTripFlowMode / ixSetTcpRoundTripFlowMode

• disableUdfs

• Start Transmit

• ixStartPortTransmit / ixStartTransmit / ixStopPortTransmit / ixStopTrans-mit

• ixStartStaggeredTransmit

• ixCheckPortTransmitDone / ixCheckTransmitDone

• ixStartPortCollisions / ixStartCollisions / ixStopPortCollisions / ixStop-Collisions

• Calculation Utilities

• calculateFrameRate

• calculateGap

• validateFramesize

• validatePreamblesize

• host2addr

• byte2IpAddr

• dectohex

• hextodec

Setup ixCheckLinkState

The ixCheckLinkState command checks the link state on a group of ports. This command should be called early in the script to ensure that all links are up before any traffic is transmitted to the DUT. The format of the command is:

ixCheckLinkState portList

where portList is the set of ports to check. A success value of 0 is returned if all of the ports have link.


High-Level and Utility API DescriptionData Transmission

Refer to “ixCheckLinkState” on page C-2 for a complete explanation of this command.

ixCheckPPPState

The ixCheckPPPState command checks the state on a group of POS ports. This command should be called early in the script to ensure that all POS ports are up before any traffic is transmitted to the DUT. The format of the command is:

ixCheckPPPState portList

where portList is the set of ports to check. A success value of 0 is returned if all of the ports have link.

Refer to “ixCheckPPPState” on page C-6 for a complete explanation of this command.

ixSetPortPacketFlowMode / ixSetPacketFlowMode

These commands set the mode of the indicated ports to flow mode as opposed to stream mode (see “Streams and Flows” on page 3-4). The format of these com-mands are:

ixSetPortPacketFlowMode chassisID cardID portID [write]

ixSetPacketFlowMode portList [write]

where chassisID, cardID, and portID identifies a single port and portList identi-fies a number of ports. The write argument will commit the settings to the hard-ware immediately.

Refer to “ixSetPortPacketFlowMode” on page C-65 and “ixSetPacketFlow-Mode” on page C-58 for a complete explanation of these commands.

ixSetPortPacketStreamMode / ixSetPacketStreamMode

These commands set the mode of the indicated ports to stream mode as opposed to flow mode (see “Streams and Flows” on page 3-4). The format of these com-mands are:

ixSetPortPacketStreamMode chassisID cardID portID [write]

ixSetPacketStreamMode portList [write]


Refer to “ixSetPortPacketStreamMode” on page C-67 and “ixSetPacketStream-Mode” on page C-62 for a complete explanation of these commands.



ixSetPortTcpRoundTripFlowMode / ixSetTcpRoundTripFlowMode

These commands set the mode of the indicated ports to TCP round trip flow mode as opposed to flow or stream mode (see “Streams and Flows” on page 3-4). The format of these commands are:

ixSetPortTcpRoundTripFlowMode chassisID cardID portID [write]

ixSetTcpRoundTripFlowMode portList [write]


Refer to “ixSetPortTcpRoundTripFlowMode” on page C-68 and “ixSetTcpRoundTripFlowMode” on page C-69 for a complete explanation of these commands.

disableUdfs

The disableUfs command disables one or more UDFs. The format of the com-mand is:

disableUdfs udfList

where udfList is a list of values in the range 1-4. For example, {1 2 3 4}. A call to stream set is needed to write these values to the hardware.

Refer to “disableUdfs” on page B-6 for a full description of this command.

Start Transmit ixStartPortTransmit / ixStartTransmit / ixStopPortTransmit / ixStopTransmit

These commands are used to start and then stop transmission on a single port or a group of ports. The ixStartCapture or ixStartPortCapture should be used before these commands. The format of these commands are:

ixStartPortTransmit chassisID cardID portID

ixStartTransmit portList

ixStopPortTransmit chassisID cardID portID

ixStopTransmit portList

where chassisID, cardID, and portID identifies a single port and portList identi-fies a number of ports.

Refer to “ixStartPortTransmit” on page C-89, “ixStartTransmit” on page C-96, “ixStopPortTransmit” on page C-116 and “ixStopTransmit” on page C-121 for complete descriptions of these commands.



ixStartStaggeredTransmit

This command performs the same function as ixStartTransmit, but staggers the time from one port’s start to the next by 25 - 30ms. The format of this com-mand is:

ixStartStaggered portList

where portList identifies a number of ports to start staggered transmission on.

Refer to “ixStartStaggeredTransmit” on page C-94 for a complete descriptions of this command.

ixCheckPortTransmitDone / ixCheckTransmitDone

These commands poll a single port or list of ports to determine when all data has been transmitted to the DUT. This command does not return until transmission is complete on all the ports referenced. Note: these commands should be called no earlier than one second after starting transmit with ixStartTransmit or ixStart-PortTransmit. It is recommended that an after 1000 statement be included after each start transmit. The format of these commands are:

ixCheckPortTransmitDone chassisID cardID portID

ixCheckTransmitDone portList


Refer to “ixCheckPortTransmitDone” on page C-7 and “ixCheckTransmit-Done” on page C-9 for a complete explanation of these commands.

ixStartPortCollisions / ixStartCollisions / ixStopPortCollisions / ixStopCollisions

These commands are used to start and then stop generation of forced collisions on a single port or list of ports. The forcedCollisions command should be used before these commands to set up the parameters for collision generation. The format of these commands are:

ixStartPortCollisions chassisID cardID portID

ixStartCollisions portList

ixStopPortCollisions chassisID cardID portID

ixStopCollisions portList


Refer to “ixStartPortCollisions” on page C-85, “ixStartCollisions” on page C-76, “ixStopPortCollisions” on page C-112 and “ixStopCollisions” on page C-102 for complete descriptions of these commands.



Calculation Utilities calculateFrameRate

The calculateFrameRate command calculates the frame rate in frames per second based on the inter-frame gap, frame size, preamble size and interface speed. The format of the command is:

calculateFrameRate ifgap frame_size frame_preambleSize speed

where ifgap is the inter-frame gap expressed in clock ticks, frame_size is expressed in bytes, frame_preambleSize is the size of the preamble expressed in bytes and speed is the interface speed expressed in Mbps. See command stream config –ifg in “stream” on page A-282 for the definition of clock ticks.

Refer to “calculateFrameRate” on page B-3 for a full description of this com-mand.

calculateGap

The calculateGap command calculates the inter-frame gap in clock tick units based on the frame rate, frame size, preamble size and interface speed. See com-mand stream config –ifg in “stream” on page A-282 for the definition of clock ticks.The format of the command is:

calculateGap frame_rate frame_size frame_preambleSize speed

where frame_rate is expressed in frames per second, frame_size is expressed in bytes, frame_preambleSize is the size of the preamble expressed in bytes and speed is the interface speed expressed in Mbps.

Refer to “calculateGap” on page B-4 for a full description of this command.

validateFramesize

The validateFramesize command checks the argument to see whether it falls in the legal range of frame sizes: 64 through 1518. The format of the command is:

validateFramesize arg

where arg is the frame size to be checked.

Refer to “validateFramesize” on page B-20 for a full description of this com-mand.

validatePreamblesize

The validatePreamblesize command checks the argument to see whether it falls in the legal range of preamble sizes: 2 through 255. The format of the com-mand is:

validatePreamblesize arg

where arg is the frame size to be checked.



Refer to “validatePreamblesize” on page B-21 for a full description of this com-mand.

host2addr

This command converts an IP address in dotted notation to a list of hex bytes. The format of the command is:

host2addr IPaddr

where IPaddr is the address in dotted notation. The result is a list of four hex byte values.

Refer to “host2addr” on page B-9 for a full description of this command.

byte2IpAddr

This command converts a list of four hex bytes into an IP address in dotted nota-tion. The format of the command is:

byte2IpAddr hexIPaddr

where hexIPaddr is the address as a list of four hex byte values. The result is a dotted notation.

Refer to “byte2IpAddr” on page B-2 for a full description of this command.

dectohex

This command converts a decimal number to hexadecimal notation. The format of the command is:

dectohex decnum

where decnum is the decimal value. The result is in hexadecimal notation.

Refer to “dectohex” on page B-5 for a full description of this command.

hextodec

This command converts a hexadecimal number to decimal notation. The format of the command is:

hextodec hexnum

where hexnum is the hexadecimal value. The result is in decimal notation.

Refer to “hextodec” on page B-8 for a full description of this command.


High-Level and Utility API DescriptionData Capture and Statistics6

Data Capture and StatisticsThe commands in this section relate to setup for data capture, initiating data cap-ture and collection of statistics. Although this section follows the one on data transmission, all capture setup and initiation should be done before any data transmission is started. The commands covered in this section are:

• Setup

• ixSetPortCaptureMode / ixSetCaptureMode

• ixSetPortPacketGroupMode / ixSetPacketGroupMode

• ixClearTimeStamp

• ixClearPortStats / ixClearStats

• ixResetSequenceIndex / ixResetPortSequenceIndex

• Capture Data

• ixStartPortCapture / ixStartCapture / ixStopPortCapture / ixStopCapture

• ixStartPortPacketGroups / ixStartPacketGroups / ixStopPortPacketGroups / ixStopPacketGroups

• Statistics

• ixCollectStats

Setup The data capture and statistics setup commands should be performed before any data capture operations are started.

ixSetPortCaptureMode / ixSetCaptureMode

These commands sends a message to the IxServer to set the receive mode of a single port or list of ports to Capture mode. This mode must be used when traffic is to be captured in the capture buffer. This mode is mutually exclusive with the Packet Group receive mode. The format of these commands are:

ixSetPortCaptureMode chassisID cardID portID [write]

ixSetCaptureMode portList [write]


Refer to “ixSetPortCaptureMode” on page C-64 and “ixSetCaptureMode” on page C-56 for a full description of these commands.

ixSetPortPacketGroupMode / ixSetPacketGroupMode

These commands send a message to the IxServer to set the receive mode of a sin-gle port or list of ports to Packet Group mode. This mode must be used when


High-Level and Utility API DescriptionData Capture and Statistics

real-time latency metrics are to be obtained. This mode is mutually exclusive with the Capture receive mode. The format of these commands are:

ixSetPortPacketGroupMode chassisID cardID portID [write]

ixSetPacketGroupMode portList [write]


Refer to “ixSetPortPacketGroupMode” on page C-66 and “ixSetPacketGroup-Mode” on page C-60 for a full description of these commands.

ixClearTimeStamp

The ixClearTimeStamp command sends a message to the IxServer to synchro-nize the timestamp on a group of chassis. This feature is useful for calculating latency on ports across chassis. The format of this command is:

ixClearTimeStamp portList

where portList identifies a number of ports.

Refer to “ixClearTimeStamp” on page C-17 for a full description of this com-mand.

ixClearPortStats / ixClearStats

These commands clear all of the statistics counters on a single port or list of ports. The format of these commands is:

ixClearPortStats chassisID cardID portID

ixClearStats portList


Refer to “ixClearPortStats” on page C-14 and “ixClearStats” on page C-15 for a full description of these commands.

ixResetSequenceIndex / ixResetPortSequenceIndex

These commands send a message to the IxServer to reset the sequence index of a single port or a list of ports. The format of these commands are:

ixResetPortSequenceIndex chassisID cardID portID [write]

ixResetSequenceIndex portList [write]



High-Level and Utility API DescriptionData Capture and Statistics6

Refer to “ixResetSequenceIndex” on page C-54 and “ixResetPortSequenceIn-dex” on page C-53 for a full description of these commands.

Capture Data ixStartPortCapture / ixStartCapture / ixStopPortCapture / ixStopCapture

These commands start and stop port capture on a single port or on a group of ports. The format of these commands is:

ixStartPortCapture chassisID cardID portID

ixStartCapture portList

ixStopPortCapture chassisID cardID portID

ixStopCapture portList

where chassisID, cardID, and portID identify a single port and portList identifies a number of ports.

Refer to “ixStartPortCapture” on page C-84, “ixStartCapture” on page C-74, “ixStopPortCapture” on page C-110 and “ixStopCapture” on page C-100 for complete descriptions of these commands.

ixStartPortPacketGroups / ixStartPacketGroups / ixStopPortPacketGroups / ixStopPacketGroups

These commands start and stop calculation of real-time latency metrics on a sin-gle port or on a group of ports. The minimum, maximum and average latencies will be calculated for each packet group ID (PGID). The format of these com-mands is:

ixStartPortPacketGroups chassisID cardID portID

ixStartPacketGroups portList

ixStopPortPacketGroups chassisID cardID portID

ixStopPacketGroups portList


Refer to “ixStartPacketGroups” on page C-82, “ixStartPacketGroups” on page C-82, “ixStopPortPacketGroups” on page C-114 and “ixStopPacketGroups” on page C-108 for complete descriptions of these commands.

Statistics ixCollectStats

This command gathers the same specified statistic from a number of ports and places the results in a return array. The format of this command is:

ixCollectStats portList statName RxStats TotalStats


High-Level and Utility API DescriptionData Capture and Statistics

where portList identifies a number of ports to collect statistics from, statName is the name of the statistic to collect, RxStats is the returned array of statistics and TotalStats is the returned total number of frames. statName must match one of the standard options defined in the stat command (see “stat” on page A-262). RxStats is an array whose indices are the ports over which the statistics were col-lected.

Note that the RxStats indices are separated by commas and not spaces as in other array references used with maps. Also recall that most of the statistics collected are 64-bit values, as indicated in the stat command. Calculations on these values should be performed using the mpexpr command.

Refer to “ixCollectStats” on page C-19 for a full description of this command.


High-Level and Utility API DescriptionProtocol Server6

Protocol ServerVarious features are controlled by a set of port software called the protocol server. The protocol server understand and deals with high-level protocols. The commands in this section are:

• Check for Installed Software

• ixUtils

• isArpInstalled / isBgpInstalled / isIgmpInstalled / isIsisInstalled / isOspfIn-stalled / isRipInstalled / isRsvpInstalled

• ARP

• ixEnableArpResponse / ixEnablePortArpResponse

• ixDisableArpResponse / ixDisablePortArpResponse

• ixClearPortArpTable / ixClearArpTable

• ixTransmitPortArpRequest / ixTransmitArpRequest

• IGMP

• ixTransmitIgmpJoin

• ixTransmitIgmpLeave

• BGP4

• ixStartBGP4 / ixStopBGP4

• OSPF

• ixStartOSPF / ixStopOSPF

• ISIS

• ixStartISIS / ixStopISIS

• RIP

• ixStartRIP / ixStopRIP

• RSVP

• ixStartRSVP / ixStopRSVP

Check for Installed Software

The two commands in this section allow a Tcl program to check if optional rout-ing protocol support software is installed. ixUtils can be used for all of these functions, or isXXXInstalled may be used for each protocol.

ixUtils

ixUtils is called with one of the following arguments to determine if software has been installed:

• isArpInstalled

• isBgpInstalled


High-Level and Utility API DescriptionProtocol Server

• isIgmpInstalled

• isIsisInstalled

• isOspfInstalled

• isRipInstalled

• isRsvpInstalled

isArpInstalled / isBgpInstalled / isIgmpInstalled / isIsisInstalled / isOspfInstalled / isRipInstalled / isRsvpInstalled

These commands are wrappers which provide access to the corresponding ixUtils isXXXInstalled usage.

ARP All of the commands in this section require that the ip command be used on the port(s) before any ARP command.

ixEnableArpResponse / ixEnablePortArpResponse

These commands enable ARP response to ARP requests on a single port or list of ports. The format of these commands is:

ixEnablePortArpResponse chassisID cardID portID

ixEnableArpResponse portList


Refer to “ixEnableArpResponse” on page C-31 and “ixEnablePortArpRe-sponse” on page C-33 for a full description of these commands.

ixDisableArpResponse / ixDisablePortArpResponse

These commands disable ARP response to ARP requests on a single port or list of ports. The format of these commands is:

ixDisablePortArpResponse chassisID cardID portID

ixDisableArpResponse portList


Refer to “ixDisableArpResponse” on page C-26 and “ixDisablePortArpRe-sponse” on page C-28 for a full description of these commands.

ixClearPortArpTable / ixClearArpTable

These commands clear all of the statistics counters on a single port or list of ports. The format of these commands is:

ixClearPortArpTable chassisID cardID portID



ixClearArpTable portList


Refer to “ixClearPortStats” on page C-14 and “ixClearStats” on page C-15 for a full description of these commands.

ixTransmitPortArpRequest / ixTransmitArpRequest

These commands signal the protocol server to start transmission of Arp requests as indicated through the arpServer command on a single port or list of ports. The format of these commands is:

ixTransmitPortArpRequest chassisID cardID portID

ixTransmitArpRequest portList

where chassisID, cardID, and portID identifies a single port and portList identi-fies a number of ports. Refer to “ixTransmitPortArpRequest” on page C-130 and “ixTransmitArpRequest” on page C-124 for a full description of these com-mands.

IGMP ixTransmitIgmpJoin

This command sends a message to the IxServer to start transmission of IGMP membership messages for a list of ports. The format of these commands is:

ixTransmitIgmpJoin portList [groupId]

where portList identifies a number of ports and groupId is the optional group ID number to use (101064 is the default).

Refer to “ixTransmitIgmpJoin” on page C-126 for a full description of this com-mand.

ixTransmitIgmpLeave

This command sends a message to the IxServer to start transmission of IGMP membership leave messages for a list of ports. The format of these commands is:

ixTransmitIgmpLeave portList [groupId]

where portList identifies a number of ports and groupId is the optional group ID number to use (101064 is the default).

Refer to “ixTransmitIgmpLeave” on page C-128 for a full description of this command.


High-Level and Utility API DescriptionProtocol Server

BGP4 ixStartBGP4 / ixStopBGP4

These commands start and stop the BGP4 component of the Protocol Server for a list of ports. The format of these commands is:

ixStartBGP4 portList

ixStopBGP4 portList

Refer to “ixStartBGP4” on page C-72 and “ixStopBGP4” on page C-98 for a full description of these commands.

OSPF ixStartOSPF / ixStopOSPF

These commands start and stop the OSPF component of the Protocol Server for a list of ports. The format of these commands is:

ixStartOSPF portList

ixStopOSPF portList

Refer to “ixStartOspf” on page C-80 and “ixStopOspf” on page C-106 for a full description of these commands.

ISIS ixStartISIS / ixStopISIS

These commands start and stop the ISIS component of the Protocol Server for a list of ports. The format of these commands is:

ixStartISIS portList

ixStopISIS portList

Refer to “ixStartIsis” on page C-78 and “ixStopIsis” on page C-104 for a full description of these commands.

RIP ixStartRIP / ixStopRIP

These commands start and stop the RIP component of the Protocol Server for a list of ports. The format of these commands is:

ixStartRIP portList

ixStopRIP portList

Refer to “ixStartRip” on page C-90 and “ixStopRip” on page C-117 for a full description of these commands.

RSVP ixStartRSVP / ixStopRSVP

These commands start and stop the RSVP component of the Protocol Server for a list of ports. The format of these commands is:

ixStartRSVP portList



ixStopRSVP portList

Refer to “ixStartRsvp” on page C-92 and “ixStopRsvp” on page C-119 for a full description of these commands.


High-Level and Utility API DescriptionConsole Output and Logging

Console Output and LoggingThe commands in this section relate to textual output to the console and to the operation of the log file. The commands covered in this section are:

• Console Output

• ixPuts

• Logging

• logOn / logOff

• logMsg

• logger

Console Output ixPuts

Refer to “ixPuts” on page C-52 for a full description of this command. The ixPuts command outputs its arguments to the console window with or without a newline. The format of the command is:

ixputs [-nonewline] arg...

where -nonewline indicates that a newline should not be appended to the output and arg... is any number of arguments, which will be concatenated and printed.

Logging logOn / logOff

These commands enable and disable logging. The logOn command also defines the name of the log file. The format of these commands are:

logOn filename

logOff

where filename is the name of the log file to be created.

Refer to “logOn” on page B-14 and “logOff” on page B-13 for a full description of these commands.

logMsg

The logMsg command outputs its arguments to the log file with or without a newline. The format of the command is:

logMsg [-nonewline] arg...

where -nonewline indicates that a newline should not be appended to the output and arg... is any number of arguments, which will be concatenated and logged.

Refer to “logMsg” on page B-12 for a full description of this command.


High-Level and Utility API DescriptionConsole Output and Logging6

logger

The logger command is the underlying command behind logOn, logOff, logMsg and ixInitialize. The standard options and sub-commands of this command are:

Refer to “logger” on page B-15 for a full description of this command.

TABLE 6-4. logger Options

Member Usage

fileBackup If this flag is true, then the current log file will be renamed before a new one is created.

logFileName The name of the log file; default is default.log.

directory The name of the log directory; default is c:\Program Files\ixia\TclScripts\Logs.

TABLE 6-5. logger Sub-Commands

Member Usage

message Writes a message to the log file.

off Turns off logging.

on Turns on logging.

show Shows the current logging parameters.


7— A —

ACCM See Asynchronous Control Character Mask.

ACK An acknowledge signal or message. For IP session establishment, an ACK message is sent in response to a SYN message.

Address Resolution Protocol

The Internet protocol used to map an IP address to a MAC address. Defined in RFC 826.

Advanced Stream Scheduler

An Ixia hardware capability for some POS cards that allows an interleaved set of streams to be sent to the DUT.

AIS-L Alarm Indication Signal used in POS transmissions. Included as a setting in the K2 byte.

API See Application Programming Interface.

Application Programming Environment

A set of supplied program modules and environment used to provide support in building a software application.

ARP See Address Resolution Protocol.

APS See Automatic Protection Switching.

AS See Autonomous System and Available Seconds.

Asynchronous Control Character Mask

A 32-bit mask that represents control characters with ASCII values 0 through 31. If a bit is set to 1, PPP encodes the corresponding control character before sending it over the link.

Asynchronous Interrupt

An event that can happen at any time. In the Ixia system, an asynchronous interrupt can trigger the transmission of an asynchronous region.

Asynchronous Region A set of streams which can be triggered and transmitted at any time.

Automatic Protection Switching

A technique used in Packet over Sonet networks to switch working channels to backup protection channels.

Auto-Negotiation The algorithm that allows two devices at either end of a link segment to negotiate common data service functions.

Glossary


7

Autonomous System A collection of routers that implement the same routing policy and are typically administered by a single group of administrators. ASs connected to the Internet are assigned numbers called ASNs (autonomous system numbers) which are key to inter-domain routing

Available Seconds During PoS data reception, the seconds during which the block state was in an available condition; generally error free for 10 seconds or more.

— B —

Base Station In wireless networks, the non-mobile part of the connection. The base station is responsible for sending and receiving data to Mobile Stations and wide-area networks.

BERT See Bit Error Rate Testing.

BIP Errors Bit Interleaved Parity errors found in POS circuits. BIP errors can occur as Section, Line or Parity Errors.

Bit Error Rate Testing An OSI Layer 1/2 test in which low level data integrity is tested.

BGP See Border Gateway Protocol.

BOOTP Bootstrap Protocol. Protocol used by a network node to determine the IP address of its Ethernet interfaces, in order to affect network booting.

Border Gateway Protocol

The principal protocol used along the Internet backbone and within larger organizations

BPDU Bridge Protocol Data Unit. A spanning-Tree Protocol hello packet that is sent out at configurable intervals to exchange information among bridges in the network.

BS See Base Station.

Burst A counted number of data packets, each separated by an Inter-Packet Gap (IPG).

— C —

C/C++ A pair of related computer programming languages. Ixia supplies an API for the use of C++ in test development.

Cable Modem The CPE in a cable data system. The Cable Modem handles RF signals from the cable network and ethernet/USB signals on the local network.

Cable Modem Termination System

The central office equipment in a cable data network. The CMTS handles RF signals form the cable network and ethernet signals to the wide-area network.


Capture A basic receive mode—as opposed to packet group mode.

Capture Buffer A memory area associated with each port. Data is captured after the Capture Trigger is satisfied and the Capture Filter allows data to be recorded.

Capture Filter A set of conditions that determine which data is recorded in a port’s capture buffer.

Capture Trigger A set of conditions that determine which when data is starts to record in a port’s capture buffer.

Card See Card Module.

Card Module A plug-in card that fits within an Ixia Chassis and contains one or more ports.

Cascading UDF A feature of the Ixia User Defined Fields that allows counting to continue from previous streams.

CDMA Code-Division Multiple Access. A technique used in cellular phone/data systems to allow multiple coded transmissions on the same frequency range.

Chassis An Ixia chassis, containing a card frame into which Card Modules are plugged in. A Chassis also contains an Intel processor (or equivalent), disk and network adapter.

Channelized A transmission option for subscribers of symmetrical services. Channelized service allows a subscriber to assign one device (such as a PC) to a DS0 channel, resulting in many devices being able to transmit and receive simultaneously at 64 kbps.

Chassis Chain A set of Chassis connected together with special cables such that ports in different chassis may initiate transmission (nearly) simultaneously.

Checksum A value calculated from packet data which, when included with the packet, may be used to guarantee the validity of received data.

Cisco Frame Relay A Cisco proprietary version of Frame Relay.

Class In C++ programming, the definition of a set of related data members and subroutine methods used to implement operations of a particular type or on a particular set of data.

CM See Cable Modem.

CMTS See Cable Modem Termination System.

Collision A condition that results from concurrent transmissions from multiple sources.


7

Collision Backoff An algorithm which each transmitting party uses to determine when to attempt a retransmit in the event of a collision.

Concatenated A transmission option for subscribers of symmetrical services. Concatenated service applies all of the bandwidth to a single stream.

CRC See Cyclic Redundancy Check.

Cyclic Redundancy Check

An error-checking technique in which the frame recipient calculates a remainder by dividing the frame contents by a prime binary divisor and compares the calculated remainder to a value stored in the frame by the sending node.

— D —

DA See Destination Address.

Datagram (IP) Fundamental unit of information passed across the Internet. Contains source and destination addresses along with data and a number of fields that define such things as the length of the datagram, the header checksum, and flags to indicate whether the datagram can be (or was) fragmented.

Data Link Layer Layer 2 of the OSI reference model. Provides reliable transit of data across a physical link. The data-link layer is concerned with physical addressing, network topology, line discipline, error notification, ordered delivery of frames, and flow control. The IEEE divided this layer into two sublayers: the MAC sublayer and the LLC sublayer. Sometimes simply called link layer.

Default Gateway In IP routing procedures, the IP address of a routing device to send all packets that are not otherwise directed by a routing protocol. In Ixia testing, the DUT is often the Default Gateway.

Delay (IP) An IP header bit that indicates that the sender is interested in minimizing packet delay.

Device Under Test The networking or other device that is being tested through a combination of input data and sensed output data.

Destination Address A Data Link Layer field that indicates the MAC level destination of the packet.

DHCP Dynamic Host Control Protocol. DHCP provides a mechanism for allocating IP addresses dynamically so that addresses can be reused when hosts no longer need them.

DIX A bit-oriented Ethernet header which uses bit stuffing.

Domain Name System The system used in the Internet for translating names of network nodes into addresses.


DNS See Domain Name System.

Dribble Bit Error An error condition that occurs when additional data follows the FCS at the end of a packet.

Duplex Mode The mode of an Ethernet port - either half-duplex or full-duplex.

DUT See Device Under Test.

— E—

EFS See Error Free Seconds.

Egress Router In MPLS routing networks, the router by which the network was entered.

Errored Blocks In POS, the number of blocks in which one or more bits are in error.

Error Free Seconds For PoS received data, the number of one-second periods for which no bit error or defect was detected.

Errored Seconds For PoS received data, the number of one-second periods with one or more errored blocks or at least on defect.

ES See errored seconds.

Ethernet A baseband LAN specification invented by Xerox Corporation and developed jointly by Xerox, Intel, and Digital Equipment Corporation. Ethernet networks use run over a variety of cable types at 10/100/1000 Mbps. Ethernet is similar to the IEEE 802.3 series of standards.

— F —

Farm See Server Farm.

FCS See Frame Check Sequence.

Filter See Capture Filter.

FIN A TCP packet with the FIN bit set. This is used by one party in a connection to end a TCP connection.

FIN-ACK A TCP packet with the FIN and ACK bits set. This is used by a party in a connection to acknowledge the conclusion of a connection.

FIR See Frame Identity Record.


7

Flags (IP) A 3-bit flag of the IP header that deals with IP fragments.

Flow A means of programming the Ixia transmit hardware so as to allow thousands of unique packets. These packets are pre-generated in software.

FPGA Field Programmable Gate Arrays. These are programmable elements of the Ixia chassis and cards, downloaded by IxServer as needed.

Frame A set of data formatted according to a data link standard, such as Ethernet or 802.3. Also referred to as a packet.

Frame Check Sequence

Extra characters added to a frame for error control purposes. See CRC.

Frame Identity Record An Ixia port capability that allows additional data to inserted at the end of the data part of a packet. This data can be used to locate the source of the frame when the frame is received in a capture buffer

Frame Relay A high-speed, packet-mode data communications protocol based on ITU-T recommendation I.122 and the link access procedure on the D channel (LAPD) specification. It is specifically designed for transport over today's reliable high-speed digital facilities.

Frame Size The overall size of the frame, including the FCS.

Full Duplex The ability of a communications device to both transmit and receive at the same time.

— G—

GBIC An input/output device that plugs into a Gigabit ethernet port, linking the module port with the fiber-optic network

Gigabit A network operating at 1000 Mbps.

Global Positioning System

The Global Positioning System is a "constellation" of 24 well-spaced satellites that orbit the Earth and make it possible for people with ground receivers to pinpoint their geographic location. An additional benefit of GPS is the ability to derive a very accurate time-of-day.

GPS See Global Positioning System.

— H —

HAL Hardware Abstraction Layer. A layer of software used to isolate the user input software from the actual hardware control.


Half Duplex The characteristic of a communications device that it can only transmit or receive data.

HSA High bits of Source Address. The high order 24 bits of an ISL packet’s source address.

— I —

IBG See Inter-Burst Gap.

IEEE 802.3 IEEE LAN protocol that specifies an implementation of the physical layer and the MAC sublayer of the data link layer.

ICMP (Internet Control Message Protocol) A network layer Internet protocol that reports errors and provides other information relevant to IP packet processing. Documented in RFC 792.

Identification (IP) An element of the IP header which identifies the datagram that the fragment belongs to.

IGMP Internet Group Management Protocol. Used by IP hosts to report their multicast group memberships to an adjacent multicast router.

Ingress Router In MPLS routing networks, the router by which the network was exited.

Inter-Burst Gap The amount of time inserted between multiple bursts in a stream.

Intermediate System In OSI routing, including IS-IS, an Intermediate System is a router or other device that forwards as opposed to generates or uses traffic.

Inter-Packet Gap The amount of time inserted between consecutive packets in a burst.

Inter-Stream Gap The amount of time preceding each stream in a region.

IP See IPv4 and IPv6.

IPv4 Internet Protocol version 4. The network layer protocol in the TCP/IP stack offering a connection-less internetwork service. IP provides features for addressing, type-of-service specification, fragmentation and reassembly, and security. Defined in RFC 791.

IPv6 Also known as IPNG (IP Next Generation). A number of improvements over IPv4, including the use of 128-bit IP addresses.

IPG See Inter-Packet Gap.


7

IPX Internetwork Packet Exchange. NetWare network layer (Layer 3) protocol used for transferring data from servers to workstations.

IS See Intermediate System.

IS-IS An OSI/IP routing technique, Intermediate System to Intermediate System. I.e. router to router.

ISG See Inter-Stream Gap.

ISL Inter-Switch Link. A protocol used to inter-connect two VLAN capable ethernet switches.

IxClock An Ixia device that features a GPS, rubidium oscillator and additional timing inputs. An IxClock is used in conjunction with another standard Ixia chassis.

IxServer A software module that resides on an Ixia chassis and receives commands from Unix machines running ScriptMate or TCL-based code.

— J —

Jitter The standard deviation of latency measurements.

— K —

K1 / K2 Two control bytes used in POS APS.

— L —

Label Switched Path In MPLS and RSVP-TE, a path through a number of routers from an ingress to an egress router that has been established through the use of labels used in Label Switching Routers.

Label Switching Routers

In MPLS and other label switching environments, routers that switch traffic based on labels.

Latency The delay between the time a device receives a frame and the time that frame is forwarded out the destination port.

LCP See Line Control Protocol.

Line Errors A particular type of BIP Errors found or inserted in POS systems.

Linear APS Implementation of a POS APS for an arrangement of nodes that are configured as a string


Line Control Protocol A part of the PPP protocol used to control the communications line.

Line Speed For 10/100/1000 Mbps ports, the choice of which speed is selected.

Link State Advertisement

An element of an OSPF message that indicates the state of a router’s link, including additional attributes.

Load Balancing See Server Load Balancing.

Loopback The condition in which a port’s transmitter and receiver are connected together to test basic port operation.

LSA See Link State Advertisement.

LSP See Label Switched Path.

LSR See Label Switching Routers.

— M —

MAC see Media Access Control.

Magic Number A PPP negotiation feature used primarily to detect looped connections.

Media Access Control The data link sublayer that is responsible for transferring data to and from the Physical Layer.

Member In C++ programming, a data item associated with a Class.

Method In C++ programming, a subroutine associated with a Class.

MII Registers Media Independent Interface. A set of data registers which control the operation of the PHY.

Mobile Station In a wireless network, the mobile component of the system. It deals with CDMA signal to ethernet signal translation.

MPLS Multi-protocol layered switching. A protocol for controlling wide area routing.

MS See Mobile Station.

Multicast Multicast is communication between a single sender and multiple receivers on a network. Multicast addresses are assigned from the 224.*.*.* range.


7

— N —

NCP See Network Control Protocol.

Network Layer Layer 3 of the OSI reference model. This layer provides connectivity and path selection between two end systems. The network layer is the layer at which routing occurs.

Network Mask A set of bits that indicates that part of an IP address that corresponds to the network number. A network mask must have a contiguous set of ‘1’ from its MSB.

Network Node An endpoint of a network connection or a junction common to two or more lines in a network. Nodes can be processors, controllers, or workstations. Node is sometimes used generically to refer to any entity that can access a network, and is frequently used interchangeably with device.

Network Number That part of an IP address that corresponds to the network being addressed. Formed by anding the Network Mask with the IP address.

Network Socket Each Network Node has 64k connection endpoints called sockets that are used in IP communications.

Nibble Half of a byte; four bits.

— O —

Object See Class.

Open Shortest Path First

A set of messaging protocols that are used by routers located within a single Autonomous System (AS).

OSPF See Open Shortest Path First.

— P —

Packet A logical grouping of information that includes a header containing control information and user data. Packets are most often used to refer to network layer units of data. The terms datagram, frame, message, and segment are also used to describe logical information groupings at various layers of the OSI reference model.

Packet groups A basic mode of Ixia ports which allows transmitted packets to be grouped by the inclusion of an ID within the packet. The Ixia receive hardware then has the ability to categorize latency for each distinct packet group.


Packet over Sonet The ability to include IP packets within SONET payloads.

Path Errors A particular type of BIP Errors found or inserted in POS systems.

PDU See Protocol Data Unit.

PHY Physical Layer entity. The PHY contains the functions that transmit, receive and manage the encoded signals that are impressed on and recovered from the physical medium.

Point to Point Protocol A protocol used to establish point to point connections. Most often used in dial-up connections. PPP is also used in Packet Over Sonet connections and is simulated by Ixia ports.

Port In the Ixia architecture, the element of a Card Module capable of transmitting and receiving network data.

POS See Packet over Sonet.

PPP See Point to Point Protocol.

Preamble An initial set of data preceding a packet. Data bytes all of the form 0xAA and is normally 8 bytes in length.

Preamble Size The size of the preamble.

Precedence (IP) A 3-bit field that indicates the type of service desired for a packet.

Protocol A formal description of a set of rules and conventions that govern how devices on a network exchange information.

Protocol Server An aspect of the Ixia Hardware that allows handling of IP to MAC mapping, BGP, OSPF, IGMP, IS-IS, RSVP and RIP testing.

Pseudo-Random A set of repeatable data patterns that exhibits random distributions of bits.

— Q —

QoS See Quality of Service.

Quality of Service A measure of performance for a transmission system that reflects its transmission quality and service availability. QoS flags are available in IP headers and may be set and measured with the Ixia system.


7

— R —

RDI-L Remote Defect Indicator. Included as a setting in the K2 byte.

Receive Mode An Ixia port’s basic mode of operation—either capture or packet group.

Region In the Ixia architecture, a set of related Streams.

Request Reverse Option

An RSVP-TE option that requests that a complete list of routers be constructed by reverse message transmission.

Resource Reservation Protocol – Traffic Engineering

A subset of the entire RSVP protocol related to Traffic Engineering (TE). This protocol implements an assignment of labels from ingress to egress routers, with consideration for bandwidth and other QoS requirements.

Ring APS Ring APS signalling provides protection switching for bi-directional line-switched rings. Ixia cards do not perform any Automatic Protection Switching between Ixia cards. APS may be forced on the cards under test by modifying the K1/K2 bytes sent from the Ixia port.

RIP Routing Information Protocol. The Internet gateway protocol supplied with UNIX BSD systems. The most common IGP in the Internet. RIP uses hop count as a routing metric.

RoundTrip Flows An Ixia technique by which packets are reflected back to their source and the round trip time measured.

Router ID In routing protocols, a unique number associated with the router. Often one of its IP addresses.

RRO See Request Reverse Option.

RSVP-TE See Resource Reservation Protocol – Traffic Engineering.

— S —

SA See Source Address.

ScriptGen An Ixia tool for generating Tcl setup scripts from active port configurations.

SDK See Application Programming Interface.

Section Errors A particular type of BIP Errors found or inserted in POS systems.

Server Farm A set of servers delivering the same information content.


Server Load Balancing A set of tests for SLB switches, which route incoming traffic to servers in a server farm.

SES See Severely Errored Seconds.

Severely Errored Seconds

For PoS received traffic, the number of one-second periods which contain 30% errored blocks or at least one defect.

SFD See Start Field Descriptor.

Simple Network Transport Protocol

A protocol use by applications to contact a time server, in order to obtain current time-of-day data.

SLB See Server Load Balancing.

Slice Size In the Ixia architecture, the amount of data saved in a port’s capture buffer, per packet.

Software Development Kit

See Application Programming Interface.

Source Address A Data Link Layer field that indicates the MAC level source of the packet.

SNTP See Simple Network Transport Protocol.

Speed Selection For 10/100/1000 Mbps ports, the choice of which speed is selected.

Split Horizon A technique used in RIP routers whereby the RIP router does not absorb received routes into its own routing table.

SRP See Spatial Reuse Protocol.

Spatial Reuse Protocol A Cisco-developed MAC-layer protocol that enables IP routers to be connected directly to optical ring topologies. Interconnecting devices connect directly to fiber via SRP modules without the need for Sonet equipment.

Start Field Descriptor A single byte with a value of 0xAD that separates the preamble of a packet from its header.

Stream In the Ixia architecture, a set of transmitted data that consists of a number of bursts, each burst containing a number of packets.

SYN A TCP packet with the SYN bit set. This is the start of a TCP session establishment

SYN-ACK A TCP packet with the SYN and ACK bit set. This is the acknowledgement from the second part of the start of communications.


7

— T —

Tcl Short for Tool Command Language. Tcl is an interpreted programming language. Ixia supplies an API to use Tcl in network testing.

TCP Transmission Control Protocol. A connection-oriented transport layer protocol that provides reliable full-duplex data transmission. TCP is part of the TCP/IP protocol stack.

TE See RSVP-TE.

Time to Live (IP) An element of the IP header that indicates how many more hops a packet is allowed to take.

Time Stamp An element of the FIR. See Frame Identity Record.

TOS (IP) See Precedence (IP).

Transport Layer Layer 4 of the OSI reference model. This layer is responsible for reliable network communication between end nodes. The transport layer provides mechanisms for the establishment, maintenance, and termination of virtual circuits, transport fault detection and recovery, and information flow control.

Trigger See Capture Trigger.

TTL (IP) See Time to Live (IP).

Tunnel ID In RSVP-TE, an identification of a flow within a LSP (Label Switched Path).

Type-3 A generic type of many Ixia modules with limited capabilities.

— U —

UAS See Unavailable Seconds.

UDF See User Defined Fields.

UDP User Datagram Protocol. A connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768.

UDS See User Defined Statistics.

Unavailable Seconds During PoS data reception, the seconds during which the block state was in an unavailable condition; generally an error condition within the last 10 seconds.


Unicast Communication between a single sender and a single receiver over a network.

Universal Serial Bus USB (Universal Serial Bus) is a plug and play interface between a computer and add-on devices (such as audio players, joysticks, keyboards, telephones, scanners, and printers). The USB peripheral bus standard was developed by Compaq, IBM, DEC, Intel, Microsoft, NEC, and Northern Telecom and the technology is available without charge for all computer and device vendors.

USB See Universal Serial Bus.

User Defined Fields In the Ixia Architecture, one of four 32-bit counters which can be configured in a number of ways in order to generate data patterns within packets.

User Defined Statistics In the Ixia architecture, the ability of the user to define up to four statistics based on packet contents, errors and size.

— V —

VLAN Virtual LAN. A technique by which a number of nodes on one or more networks form a virtual network.

— W —

Workspace A file on the workstation disk that stores the state of an IxExplorer session.

— X —

— Y —

— Z —


7


AAppendix A: IxTclHAL Commands

Ixia Tcl Development Guide A-1

arpA

NAME - arparp - configure the ARP parameters on a stream of a port.

SYNOPSIS arp sub-command options

DESCRIPTION The arp command is used to configure the ARP parameters on a stream of a port to transmit ARP frames. Any number of varying ARP frames may be generated.

STANDARD OPTIONS

destHardwareAddr The MAC address of the interface receiving the ARP message. (default = 00 de bb 00 00 01)

destHardwareAddrMode

Indicates how the destHardwareAddr field is to vary between consequtive frames. One of:

destHardwareAddrRepeatCount

Indicates the repeat count for the destHardwareAddrMode increment and decrement options. (default = 0)

destProtocolAddr Protocol address of the station that is receiving the ARP message. (default = 127.0.0.1)

destProtocolAddrMode Indicates how the destProtocolAddr field is to vary between consequtive frames. One of:

destProtocolAddrRepeatCount

Indicates the repeat count for the destProtocolAddrMode increment and decrement options. (default = 0)

hardwareAddrLength Read-Only. Number of bytes in the hardware address. (default = 6)

Option Value Usage

arpIdle 0 (default) no change

arpIncrement 1 increment by 1 for the count in destHardwareAddrRepeatCount.

arpDecrement 2 decrement by 1 for the count in destHardwareAddrRepeatCount.

arpContinuousIncrement 3 increment by 1 continuously.

arpContinuousDecrement 4 decrement by 1 continuously.

Option Value Usage


arpIncrement 1 increment by 1 for the count in destProtocolAddrRepeatCount.

arpDecrement 2 decrement by 1 for the count in destProtocolAddrRepeatCount.



A-2 Ixia Tcl Development Guide

arp

miiaehardwareType Read-Only. Indicates the hardware type that the physical layer of the network is using. Available option values are:

operation The type of operation the ARP process is attempting. Available options are:

protocolAddrLength Read-Only. Number of bytes that each of the protocol addresses, source and target, will contain in the ARP frame. (default = 4)

protocolType Read-Only. Indicates the type of network protocol address the local network (or subnet) is using. (default = 0x0800)

sourceHardwareAddr The MAC address of the interface sending the ARP message. (default = 00 de bb 00 00 00)

sourceHardwareAddrMode

Indicates how the sourceHardwareAddr field is to vary between consequtive frames. One of:

sourceHardwareAddrRepeatCount

Indicates the repeat count for the sourceHardwareAddrMode increment and decrement options. (default = 0)

sourceProtocolAddr Protocol address of the station that is sending the ARP message. (default =127.0.0.1)

sourceProtocolAddrMode

Indicates how the sourceProtocolAddr field is to vary between consequtive frames. One of:

Option Value Usage

hwTypeEthernet 1 (default) Ethernet 10 Mb

hwTypeAmateur 3 Amateur radio AX.25

hwTypeProteon 4 Proteon ProNET token ring

hwTypeChaos 5 Chaos

hwTypeIEEE 6 IEEE 802 networks

hwTypeARCNET 7 ARCNET

hwTypeHyperchannel 8 Hyperchannel

hwTypeLocalTalk 11 LocalTalk

option Value Usage

arpRequest 1 (default) ARP request

arpReply 2 ARP reply or response

rarpRequest 3 RARP request

rarpReply 4 RARP reply or response

Option Value Usage


arpIncrement 1 increment by 1 for the count in sourceHardwareAddrRepeatCount.

arpDecrement 2 decrement by 1 for the count in sourceHardwareAddrRepeatCount.



Option Value Usage



arpA

sourceProtocolAddrRepeatCount

Indicates the repeat count for the sourceProtocolAddrMode increment and decrement options. (default = 0)

COMMANDS The arp command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

arp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the arp command.

arp config option valueModify the configuration options of the arp. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for arp.

arp decode capSlice [chasID cardID portID]Decodes a captured slice/frame into the arp variables. If not an arp frame, returns TCL_ERROR. May be used to determine if the captured frame is a valid arp frame. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• The captured frame is not an ARP frame

arp get chasID cardID portIDGets the current configuration of the arp frame for port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling arp cget option value to get the value of the configuration option. Specific errors are:

• No connection to a chassis• Invalid port number

arp set chasID cardID portIDSets the configuration of the arp in IxHAL for port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the arp config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Configured parameters are not valid for this setting

arp setDefault

Sets default values for all configuration options.

arpIncrement 1 increment by 1 for the count in sourceProtocolAddrRepeatCount.

ArpDecrement 2 decrement by 1 for the count in sourceProtocolAddrRepeatCount.



Option Value Usage


arp

EXAMPLES package require IxTclHal

# In this example, ports 1 and 2 of a card are directly connected together# Port 1 transmits an ARP request and looks at the response packet# Port 2 uses its address table and protocol server to respond to the arp# request

# Connect to chassis and get chassis IDset host galaxyixInitialize $hostset chas [ixGetChassisID $host]

set card 1set txPort 1set rxPort 2

set txPortMAC {00 00 00 01 01 01}set rxPortMAC {00 00 00 01 01 02}set txIP {192.168.18.1}set rxIP {192.168.18.2}

# Useful port listsset portList [list [list $chas $card $txPort] \ [list $chas $card $rxPort]]

# Set up Transmit Port

# Nothing special about the port setupport setFactoryDefaults $chas $card $txPortport setDefault

# Stream: 1 packet to broadcast addressstream setDefaultstream config -numFrames 1# A 1 packet stream can’t go at 100%stream config -percentPacketRate 1stream config -rateMode usePercentRatestream config -sa $txPortMAC# Broadcast arp requeststream config -da {ff ff ff ff ff ff}stream config -dma stopStream

protocol setDefaultprotocol config -name ipV4protocol config -appName Arpprotocol config -ethernetType ethernetII

# Now set up the ARP request packetarp setDefaultarp config -sourceProtocolAddr $txIParp config -destProtocolAddr $rxIParp config -operation arpRequestarp config -sourceHardwareAddr $txPortMACarp config -destHardwareAddr {ff ff ff ff ff ff}arp set $chas $card $txPort

stream set $chas $card $txPort 1port set $chas $card $txPort# Set up Receive Port for automatic ARP response


arpA

# Nothing special about the port setupport setFactoryDefaults $chas $card $rxPortport setDefaultport set $chas $card $rxPort

protocol setDefaultprotocol config -ethernetType ethernetII

# Add an address table item for IP/MACipAddressTable setDefault

ipAddressTableItem setDefaultipAddressTableItem config -fromIpAddress $rxIPipAddressTableItem config -fromMacAddress $rxPortMACipAddressTableItem set

ipAddressTable addItemipAddressTable set $chas $card $rxPort

# Let the port respond to arp requestsprotocolServer setDefaultprotocolServer config -enableArpResponse trueprotocolServer set $chas $card $rxPort

# Commit to hardwareixWritePortsToHardware portList

# Make sure link is upafter 1000ixCheckLinkState portListixStartPortCapture $chas $card $txPort

ixStartPortTransmit $chas $card $txPortafter 1000ixCheckPortTransmitDone $chas $card $txPortixStopPortCapture $chas $card $txPort

# Get the ARP response from the capture buffercaptureBuffer get $chas $card $txPortif {[captureBuffer cget -numFrames] == 0} \{ ixPuts “No packets received”} \else \{ # and extract just the returned address captureBuffer getframe 1 set data [captureBuffer cget -frame] set data [string range $data 84 94] ixPuts “ARP response (IP in hex): $data”}

SEE ALSO ip


arpAddressTableEntry

NAME - arpAddressTableEntryarpAddressTableEntry - configure the ARP address table entry parameters.

SYNOPSIS arpAddressTableEntry sub-command options

DESCRIPTION The arpAddressTableEntry command is used to configure the ARP address table entry parameters.

STANDARD OPTIONS

ipAddress Read-only. IP address. (default = 0.0.0.0)

macAddress Read-only. MAC address. (default = 00 00 00 00 00 00)

COMMANDS The arpAddressTableEntry command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

arpAddressTableEntry cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the arpAddressTableEntry command.

arpAddressTableEntry config option valueModify the configuration options of the arpAddressTableEntry. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for arpAddressTableEntry.

arpAddressTableEntry get

Gets the current ARP table entry. Call this command before calling arpAddressTableEntry cget option value to get the value of the configuration option.

arpAddressTableEntry setDefault


EXAMPLES See examples under arpServer.

SEE ALSO arp


arpServerA

NAME - arpServerarpServer - configure the ARP server parameters.

SYNOPSIS arpServer sub-command options

DESCRIPTION The arpServer command is used to configure the ARP server parameters.

STANDARD OPTIONS

mode Enable the ARP mode. Mode includes:

rate Frame rate in frames per second. (default = 100)

requestRepeatCount When mode is set to arpLearnOnly or arpGatewayAndLearn, each ARP request is repeated this number of times with request gaps dictated by rate. (default = 3)

retries Number of retries. Valid range is 1 – 65535. (default = 3)

COMMANDS The arpServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

arpServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the arpServer command.

arpServer clearArpTable

Clears the ARP table. Specific errors are:• No connection to a chassis• Invalid port number• The port is being used by another user• Network problem between the client and chassis

arpServer config option valueModify the configuration options of the arpServer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for arpServer.

Option Value Usage

arpGatewayOnly 0 (default) Sends a single ARP request to each gate-way IP address using the first IP address found in the IP table entry as the source address

arpLearnOnly 1 Sends ARP requests using all of the addresses found in the IP address table as source addresses.

arpGatewayAndLearn 2 Performs both the arpGatewayOnly and arpLearnOnly operations.


arpServer

arpServer get chasID cardID portIDGets the current configuration of the arpServer frame for port portID on card car-dID, chassis chasID from its hardware. This command should be called before arpServer cget option value to get the configuration option. Specific errors are:


arpServer getEntry ipAddrGets the entry with IP address ipAddr out of the ARP table. The data is available through the arpAddressTableEntry command. Specific errors are:

• There is no arp table in the Arp Server• There are no entries in the Arp Table• The specified IP address is not in the Arp Table

arpServer getFirstEntry

Gets the first entry out of the ARP table. The data is available through the arpAd-dressTableEntry command. Specific errors are:

• There is no arp table in the Arp Server• There are no entries in the Arp Table

arpServer getNextEntry

Gets the next entry out of the ARP table. The data is available through the arpAd-dressTableEntry command.

arpServer sendArpRequest chasID cardID portIDSends ARP request for port with id portID on card cardID, chassis chasID. Spe-cific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Network problem between the client and chassis

arpServer set chasID cardID portIDSets the configuration of the arpServer in IxHAL for port with id portID on card cardID, chassis chasID by reading the configuration option values set by the arpServer config option value command. Specific errors are:


arpServer setDefault



# In this example, we assume that Card 1, ports 1 and 2 are directly# connected or through a L2 switch# We’ll set up IP address tables for both and start the arp server# on both ports. For each port, this should obtain the MAC address of# the other party.


arpServerA


# Assume card to be used is in slot 1set card 1set port1 1set port2 2set portList [list \ [list $chas $card $port1] \ [list $chas $card $port2] \

]

# IP addressesset port1IP 148.0.0.1set port2IP 148.0.0.2

# And MAC addressesset port1MAC {00 11 11 00 00 11}set port2MAC {00 11 11 00 00 22}

# Configure Port 1

# Reset the portport setFactoryDefaults $chas $card $port1port setDefaultport set $chas $card $port1

# Set up IP table with our IP-MAC and Gateway (= port2)ipAddressTable setDefaultipAddressTable config -defaultGateway $port2IP

ipAddressTableItem setDefaultipAddressTableItem config -fromIpAddress $port1IPipAddressTableItem config -fromMacAddress $port1MACipAddressTableItem config -numAddresses 1ipAddressTableItem set

ipAddressTable addItemipAddressTable set $chas $card $port1

# Clear and set up the ARP serverarpServer setDefaultarpServer clearArpTable $chas $card $port1arpServer set $chas $card $port1

# Now start the Protocol Server to allow arp responsesprotocolServer setDefaultprotocolServer config -enableArpResponse trueprotocolServer set $chas $card $port1

# Configure Port 2

# Reset the portport setFactoryDefaults $chas $card $port2port setDefaultport set $chas $card $port2

# Set up IP table with our IP-MAC and Gateway (= port1)ipAddressTable setDefaultipAddressTable config -defaultGateway $port1IP


arpServer

ipAddressTableItem setDefaultipAddressTableItem config -fromIpAddress $port2IPipAddressTableItem config -fromMacAddress $port2MACipAddressTableItem config -numAddresses 1ipAddressTableItem set

ipAddressTable addItemipAddressTable set $chas $card $port2

# Clear and set up the ARP serverarpServer setDefaultarpServer clearArpTable $chas $card $port2arpServer set $chas $card $port2

# Now start the Protocol Server to allow arp responsesprotocolServer setDefaultprotocolServer config -enableArpResponse trueprotocolServer set $chas $card $port2

# Ready to go - send our configuration to the hardwareixWritePortsToHardware portList

# And then tell each port to ARP for their respective gatewaysarpServer sendArpRequest $chas $card $port1arpServer sendArpRequest $chas $card $port2

# Wait for ARPs to be servicedafter 5000

# Port1: Get the ARP table, get the first entry and print the entryarpServer get $chas $card $port1if {[arpServer getFirstEntry]} \{ ixPuts “Port 1: No ARP table entries”}

arpAddressTableEntry getset ipi [arpAddressTableEntry cget -ipAddress]set maca [arpAddressTableEntry cget -macAddress]

ixPuts “Port 1: $ipi = $maca”

# Port2: Get the ARP table, get the first entry and print the entryarpServer get $chas $card $port2if {[arpServer getFirstEntry]} \{ ixPuts “Port 2: No ARP table entries”}

arpAddressTableEntry getset ipi [arpAddressTableEntry cget -ipAddress]set maca [arpAddressTableEntry cget -macAddress]

ixPuts “Port 2: $ipi = $maca”

SEE ALSO arp


bertA

NAME - bertbert - configure Packet over Sonet cards for Bit Error Rate Testing.

SYNOPSIS bert sub-command options

DESCRIPTION The bert command is used to configure the transmission and receive patterns for BERT testing. Deliberate errors may be inserted with the bertErrorGeneration command. Refer to “Bit Error Rate Testing (BERT)” on page 3-44 for a discus-sion on BERT testing in Ixia equipment.

STANDARD OPTIONS

enableInvertRxPatternenable / disable

If txRxPatternMode is set to independent, this indicates that the expected receive pattern is to be inverted. (default = disable)

enableInvertTxPatternenable / disable

If set, indicates that the transmitted pattern is to be inverted. (default = disable)

rxPatternIndex If txRxPatternMode is set to independent, this indicates the expected receive pattern – one of a set of predefined patterns:

rxUserPattern If the rxPatternIndex is set to user defined, then this is the expected pattern. If the pattern is shorter than the received data, then the pattern is repeated as necessary. (default = 00 00 00 00)

txPatternIndex Indicates the pattern to be transmitted – one of a set of predefined patterns:

Option Value Usage

bertPatternAllZero 8 all zeroes are expected.

bertPatternAlternatingOneZero 9 alternating ones and zeroes are expected.

bertPatternUserDefined 10 the pattern indicated in rxUserPattern is expected.

bertPattern2_11 12 the 2^11 pattern as specified in ITU-T 0151 is expected.





bertPatternAutoDetect 17 (default) the pattern is automatically detected by the receiver.

Option Value Usage

bertPatternAllZero 8 all zeroes are transmitted.

bertPatternAlternatingOneZero 9 alternating ones and zeroes are transmitted.


bert

txRxPatternMode Indicates if transmit and receive patterns are tied together or not:

txUserPattern If the txPatternIndex is set to user defined, then this is the transmitted pattern. If the pattern is shorter than the packet data size, then the pattern is repeated as necessary. (default = 00 00 00 00)

COMMANDS The bert command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

bert cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bert command.

bert config option valueModify the configuration options of the bert. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for bert.

bert get chasID cardID portIDGets the current configuration of the bert for port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling bert cget option value to get the value of the configuration option. Specific errors are:


bert set chasID cardID portIDSets the configuration of the bert in IxHAL for port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the bert config option value command. Specific errors are:

• No connection to a chassis

bertPatternUserDefined 10 the pattern indicated in txUserPattern is transmitted.

bertPattern2_11 12 the 2^11 pattern as specified in ITU-T 0151 is transmitted.

bertPattern2_15 13 (default) the 2^15 pattern as specified in ITU-T 0151 is transmitted.




Option Value Usage

Option Value Usage

bertTxRxCoupled 0 the rxPatternIndex, rxUserPattern and enabInvertRx-Pattern values are set from txPatternIndex, txUser-Pattern and enabInvertTxPattern.

bertTxRxIndependent 1 (default) transmit and receive patterns are set inde-pendently.


bertA

• Invalid port number• The port is being used by another user• Bert is not supported for this port type (PoS only)• Configured parameters are not valid for this setting

bert setDefault



# Connect to chassis and get chassis IDset host localhostixInitialize $hostset chas [ixGetChassisID $host]# Assuming that an OC48c BERT card is in slot 30set card 30set portList [list [list $chas $card 1]]

# Check for missing cardif {[card get $chas $card] != 0} \{ ixPuts “Card $card does not exist” exit}

# Get the type of card and check if it’s the correct typeset cardType [card cget -type]if {[port isValidFeature $chas $card 1 portFeatureBert] == 0} \{ ixPuts “Card $card does not have Bert capability” return 1}

# Set the options to default valuesbert setDefault

# In this example, we’ll couple the transmit and receive side# To simulate the port connected to a device which sends its data# back to the portbert config -txRxPatternMode bertTxRxCoupled

# Select inverted 2^20 pattern to transmitbert config -txPatternIndex bertPattern2_20bert config -enableInvertTxPattern enablebert set $chas $card 1ixWritePortsToHardware portList

# Now we need to send a start transmit to the port to gather statistics# and then read the statisticsixStartPortTransmit $chas $card 1after 1000# Stop statistics gatheringixStopPortTransmit $chas $card 1

# Fetch the number of bits receivedstat get statBertBitsReceived $chas $card 1set received [stat cget -bertBitsReceived]ixPuts “$received bits were received after 1 second”


bert

# Bert error generation examplebertErrorGeneration setDefault

# Set for 10^4 errorsbertErrorGeneration config -errorBitRate bert_1e4bertErrorGeneration set $chas $card 1ixWritePortsToHardware portList

# Enable statistics gatheringixStartPortTransmit $chas $card 1

# Send the error continously for 10 secondsbertErrorGeneration startContinuousError $chas $card 1after 10000bertErrorGeneration stopContinuousError $chas $card 1ixStopPortTransmit $chas $card 1

# And get the number of errored bitsstat get statBertBitErrorsReceived $chas $card 1set received [stat cget -bertBitErrorsReceived]ixPuts “$received bit errors were received after 10 seconds”

SEE ALSO bertErrorGeneration


bertErrorGenerationA

NAME - bertErrorGenerationbertErrorGeneration - configure the BERT Error Generation parameters on a Packet over Sonet port of a card on a chassis.

SYNOPSIS bertErrorGeneration sub-command options

DESCRIPTION The bertErrorGeneration command is used to configure the insertion of delib-erate errors on a port. The port must previously have been setup using the bert command. Refer to “Bit Error Rate Testing (BERT)” on page 3-44 for a discus-sion on BERT testing in Ixia equipment.

STANDARD OPTIONS

bitMask A 32-bit mask, expressed as a list of four one-byte elements, which indicates which bit in a 32-bit word is to be errored. (default = 00000000 00000000 00000000 00000001)

burstCount The number of times that the error is to be inserted. (default = 1)

burstPeriod The number of bits between error insertions. (default = 32)

burstWidth The number of bits in the error insertion; this should be set to 32 or less. (default = 32)

errorBitRate During continuous burst rate situations, this is the error rate. One of:

period If errorBitRate is set to bert_UserDefined, then this is the number of bits between error insertions. (default = 1000000000)

Option Value Usage

bert_1e2 0 An error is inserted every 2^2 (4) bits.







bert_1e9 7 (default) An error is inserted every 2^9 (512) bits.



bert_UserDefined 10 An error is inserted every period bits.


bertErrorGeneration

COMMANDS The bertErrorGeneration command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

bertErrorGeneration cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bertErrorGeneration command.

bertErrorGeneration config option valueModify the configuration options of the bertErrorGeneration. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for bertErrorGeneration.

bertErrorGeneration get chasID cardID portIDGets the current configuration of the bertErrorGeneration for port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling bertErrorGeneration cget option value to get the value of the configura-tion option. Specific errors are:


bertErrorGeneration insertSingleError chasID cardID portIDInserts a single error into the BERT stream as specified by the STANDARD OPTIONS. Specific errors are:


bertErrorGeneration set chasID cardID portIDSets the configuration of the bertErrorGeneration in IxHAL for port with id portID on card cardID, chassis chasID by reading the configuration option val-ues set by the bertErrorGeneration config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Bert is not supported for this port type (PoS only)• Configured parameters are not valid for this setting

bertErrorGeneration setDefault


bertErrorGeneration startContinuousError chasID cardID portIDContinuously inserts errors into the BERT stream, as dictated by the STAN-DARD OPTIONS. Errors are inserted once every 2^errorBitRate bits. Specific errors are:

• No connection to a chassis• Invalid port number• Bert is not supported for this port type (PoS only)


bertErrorGenerationA

bertErrorGeneration stopContinuousError chasID cardID portIDStops the continuous insertion of errors into the BERT stream. Specific errors are:

• No connection to a chassis• Invalid port number• Bert is not supported for this port type (PoS only)

EXAMPLES See examples in bert.

SEE ALSO bert


bgp4AsPathItem

NAME - bgp4AsPathItembgp4AsPathItem - contains list based route attributes, including AS set and AS sequence.

SYNOPSIS bgp4AsPathItem sub-command options

DESCRIPTION The bgp4AsPathItem is used to construct AS Path related items. These items must be added to a route item through the use of the bgp4RouteItem add-ASPathItem command. Note: bgp4AsPathItem builds a list of AS Path segments each time you call it. If you do not want to add a list of AS Path segments, call bgp4RouteItem and use the sub-command clearASPathList before calling bgp4ASPathItem.Refer to “BGP4” on page 3-19 for a discussion on BGP4 testing with Ixia equip-ment. Refer to “bpg4AsPathItem” on page 5-57 for an overview of this com-mand. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

asList A Tcl list of AS numbers. (default = { })

asSegmentType The type of list. One of:

enableAsSegment Enables the generation of an AS segment, as described by asList and asSegmentType. (default = 0)

DEPRECATED STANDARD OPTIONS

asPathConfedSeqListasPathConfedSetListasPathSeqListasPathSetListenableAsPathConfedSeqenableAsPathConfedSetenableAsPathSeqenableAsPathSetenableAsSegment

Option Value Usage

bgpSegmentAsSet 1 AS Path Set

bgpSegmentAsSequence 2 AS Path Sequence

bgpSegmentAsConfedSequence 3 AS Path Confederation Sequence

bgpSegmentAsConfedSet 4 AS Path Confederation Set


bgp4AsPathItemA

COMMANDS The bgp4AsPathItem command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

bgp4AsPathItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4AsPathItem command.

bgp4AsPathItem config option valueModify the configuration options of the bgp4AsPathItem. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for bgp4AsPathItem.

bgp4AsPathItem setDefault


EXAMPLES See examples under bgp4Server

SEE ALSO bgp4Server, bgp4InternalTable, bgp4ExternalTable, bgp4InternalNeighborItem, bgp4ExternalNeighborItem, bgp4RouteItem


bgp4ExternalNeighborItem

NAME - bgp4ExternalNeighborItembgp4ExternalNeighborItem - configure external BGP neighbors routes.

SYNOPSIS bgp4ExternalNeighborItem sub-command options

DESCRIPTION The bgpExternalNeighborItem holds information about a range of neighbor (routers). Bgp4RouteItems are added to the Neighbor with the addRouteItem command until all routeItems are added, then externalNeighborItems are added to the externalNeighborTable with the addExternalNeighbor command. Refer to “BGP4” on page 3-19 for a discussion on BGP4 testing with Ixia equipment. Refer to “bgp4InternalNeighborItem / bgp4ExternalNeighborItem” on page 5-54 for an overview of this command. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

asNumMode When rangeCount is greater than 1, this controls the AS Number assigned to additional routers. When set to 0, all simualted routers will have the same AS number as specified with the neighborAsNum option. When set to 1, routers will be assigned incrementing AS numbers starting at neighborAsNum. (default = 1)

dutIpAddress The DUT router’s IP address. (default = 0.0.0.0)

enableExternalNeighbor

Indicates that this is an exterior neighbor router. This should not be changed from its default value of 1. (default = 1)

enableLinkFlap Enables link flapping. (default = 0)

enableStaggeredStart Enables staggered start of neighbors. (default = 0)

keepAliveTime Configures the hold time for BGP sessions for this Neighbor. Keepalives are sent out every 1/3rd of this interval. With the devaul value of 90, KeepAlive messages will be sent every 30 seconds. (default = 90)

linkFlapDropTime Specifies the time, in seconds, that the simulated router will not respond or transmit. (default = 0)

linkFlapTime Specifies the time, in seconds, between flaps. (default = 0)

localIPAddress The first IP address that will be used for simulated routers. (default = 0.0.0.0)

messageTime The frequency with which UPDATE messages are sent to the DUT, expressed in milliseconds.. (default = 0)

neighborASNum The AS number for the simulated router. (default = 0)

rangeCount The number of routers to be simulated. (default = 1)

staggeredStartPeriod Duration of the start process, measured in seconds. (default = 0)


bgp4ExternalNeighborItemA

COMMANDS The bgp4ExternalNeighborItem command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

bgp4ExternalNeighborItem addRouteItem

Adds the route range created with the bgp4RouteItem command to this router. Specific errors are:

• Invalid route range parameters• The route range already exists. (Delete an old entry before adding it again)

bgp4ExternalNeighborItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4ExternalNeighborItem com-mand.

bgp4ExternalNeighborItem clearRouteList

Clears all of the route ranges associated with the command.

bgp4ExternalNeighborItem config option valueModify the configuration options of the bgp4ExternalNeighborItem. If no option is specified, returns a list describing all of the available options (see STAN-DARD OPTIONS) for bgp4ExternalNeighborItem.

bgp4ExternalNeighborItem delRouteItem

Deletes the currently accessed route item.

bgp4ExternalNeighborItem getFirstRouteItem

Gets the first route item from the list. The contents of the item are available in the bgp4RouteItem command. Specific errors are:

• The neighbor does not have any route ranges

bgp4ExternalNeighborItem getNextRouteItem

Gets the next route item in the list. The contents of the item are available in the bgp4RouteItem command. Specific errors are:

• The neighbor does not have any more route ranges

bgp4ExternalNeighborItem setDefault





bgp4ExternalTable

NAME - bgp4ExternalTablebgp4ExternalTable - configure BGP4 external neighbors.

SYNOPSIS bgp4ExternalTable sub-command options

DESCRIPTION The bgp4ExternalTable holds all the simulated External neighbor routers. Items are added to this table using the addNeighborItem command. Refer to “BGP4” on page 3-19 for a discussion on BGP4 testing with Ixia equipment. Refer to “bgp4InternalTable / bgp4ExternalTable” on page 5-54 for an overview of this command. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

enableActiveConnect If enabled, a HELLO message is actively sent when BGP testing starts. Otherwise, the port waits for the DUT to send its HELLO message. (default = 1)

retries The number of times to attempt an OPEN connection with the DUT routers before giving up. (default = 3)

retryDelay When retries are necessary, the delay in seconds between retries. (default = 120)

COMMANDS The bgp4ExternalTable command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

bgp4ExternalTable addNeighborItem

Adds a new neighbor range to the table. The neighbor range must have been con-figured using the bgp4ExternalNeighborItem command. Specific errors are:

• bgp4server select hasn’t been called• The port is being used by another user• The neighbor range parameters are invalid• This neighbor range is already in the table

bgp4ExternalTable cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4ExternalTable command.

bgp4ExternalTable clear

Clears all the neighbor ranges and their route ranges from the table in the BGP4 server. Specific errors are:

• bgp4server select hasn’t been called• The port is being used by another user


bgp4ExternalTableA

bgp4ExternalTable config option valueModify the configuration options of the bgp4ExternalTable. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for bgp4ExternalTable.

bgp4ExternalTable delNeighborItem

Deletes the currently addressed neighbor range. Specific errors are:• bgp4server select hasn’t been called• This table is empty• The port is being used by another user

bgp4ExternalTable get

Gets the configuration of the bgp4ExternalTable in IxHAL for the port selected with the bgp4Server select command. Specific errors are:

• bgp4server select hasn’t been called

bgp4ExternalTable getFirstItem

Gets the first neighbor range from the table. Specific errors are:• bgp4server select hasn’t been called• This table is empty

bgp4ExternalTable getNextItem

Gets the next neighbor range from the table. Specific errors are:• bgp4server select hasn’t been called• There are no more neighbor ranges in the table

bgp4ExternalTable set

Sets the configuration of the bgp4ExternalTable in IxHAL for the port selected with the bgp4Server select command, by reading the configuration option values set by the bgp4ExternalTable config option value command. Specific errors are:

• bgp4server select hasn’t been called• Invalid configuration• The port is being used by another user

bgp4ExternalTable setDefault





bgp4InternalNeighborItem

NAME - bgp4InternalNeighborItembgp4InternalNeighborItem - configure internal BGP neighbors routers.

SYNOPSIS bgp4InternalNeighborItem sub-command options

DESCRIPTION The bgpInternalNeighborItem holds information about a range of neighbor (rout-ers). Bgp4RouteItems are added to the Neighbor with the addRouteItem com-mand until all routeItems are added, then internalNeighborItems are added to the internalNeighborTable with the addInternalNeighbor command. Refer to “BGP4” on page 3-19 for a discussion on BGP4 testing with Ixia equipment. Refer to “bgp4InternalNeighborItem / bgp4ExternalNeighborItem” on page 5-54 for an overview of this command. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

dutIpAddress The DUT router’s IP address. (default = 0.0.0.0)

enableInternalNeighbor

Indicates that this is an interior neighbor router. This should not be changed from its default value of 1. (default = 1)

enableLinkFlap Enables link flapping. (default = 0)

enableStaggeredStart Enables staggered start of neighbors. (default = 0)

keepAliveTime Configures the hold time for BGP sessions for this Neighbor. Keepalives are sent out every 1/3rd of this interval. With the devaul value of 90, KeepAlive messages will be sent every 30 seconds. (default = 90)

linkFlapDropTime Specifies the time, in seconds, that the simulated router will not respond or transmit. (default = 0)

linkFlapTime Specifies the time, in seconds, between flaps. (default = 0)

localIPAddress The first IP address that will be used for simulated routers. (default = 0.0.0.0)

messageTime The frequency with which UPDATE messages are sent to the DUT, expressed in milliseconds.. (default = 0)

rangeCount The number of routers to be simulated. (default = 1)

staggeredStartPeriod Duration of the start process, measured in seconds. (default = 0)

COMMANDS The bgp4InternalNeighborItem command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.


bgp4InternalNeighborItemA

bgp4InternalNeighborItem addRouteItem

Adds the route range created with the bgp4RouteItem command to this router. Specific errors are:

• Invalid route range parameters• The route range already exists. (Delete an old entry before adding it again)

bgp4InternalNeighborItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4InternalNeighborItem com-mand.

bgp4InternalNeighborItem clearRouteList

Clears all of the route ranges associated with the command.

bgp4InternalNeighborItem config option valueModify the configuration options of the bgp4InternalNeighborItem. If no option is specified, returns a list describing all of the available options (see STAN-DARD OPTIONS) for bgp4InternalNeighborItem.

bgp4InternalNeighborItem delRouteItem

Deletes the currently accessed route item.

bgp4InternalNeighborItem getFirstRouteItem

Gets the first route item from the list. The contents of the item are available in the bgp4RouteItem command. Specific errors are:

• The neighbor does not have any route ranges

bgp4InternalNeighborItem getNextRouteItem

Gets the next route item in the list. The contents of the item are available in the bgp4RouteItem command. Specific errors are:

• The neighbor does not have any more route ranges

bgp4InternalNeighborItem setDefault





bgp4InternalTable

NAME - bgp4InternalTablebgp4InternalTable - configure internal BGP neighbors.

SYNOPSIS bgp4InternalTable sub-command options

DESCRIPTION The bgp4InternalTable holds all the simulated internal neighbor routers. Items are added to this table using the addNeighborItem command. Refer to “BGP4” on page 3-19 for a discussion on BGP4 testing with Ixia equipment. Refer to “bgp4InternalTable / bgp4ExternalTable” on page 5-54 for an overview of this command. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

enableActiveConnect If enabled, a HELLO message is actively sent when BGP testing starts. Otherwise, the port waits for the DUT to send its HELLO message. (default = 1)

localASNum The AS number for the routers participating in the simulated IBGP group. (default = 0)

retries The number of times to attempt an OPEN connection with the DUT routers before giving up. (default = 0)

retryDelay When retries are necessary, the delay in seconds between retries. (default = 120)

COMMANDS The bgp4InternalTable command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

bgp4InternalTable addNeighborItem

Adds a new neighbor range to the table. The neighbor range must have been con-figured using the bgp4ExternalNeighborItem command. Specific errors are:

• bgp4server select hasn’t been called• The port is being used by another user• The neighbor range parameters are invalid• This neighbor range is already in the table

bgp4InternalTable cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4InternalTable command.

bgp4InternalTable clear

Clears all the neighbor ranges and their route ranges from the table in the BGP4 server. Specific errors are:



bgp4InternalTableA

bgp4InternalTable config option valueModify the configuration options of the bgp4InternalTable. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for bgp4InternalTable.

bgp4InternalTable delNeighborItem

Deletes the currently addressed neighbor range. Specific errors are:• bgp4server select hasn’t been called• This table is empty• The port is being used by another user

bgp4InternalTable get

Gets the configuration of the bgp4InternalTable in IxHAL for the port selected with the bgp4Server select command. Specific errors are:

• bgp4server select hasn’t been called

bgp4InternalTable getFirstItem

Gets the first neighbor range from the table. Specific errors are:• bgp4server select hasn’t been called• This table is empty

bgp4InternalTable getNextItem

Gets the next neighbor range from the table. Specific errors are:• bgp4server select hasn’t been called• There are no more neighbor ranges in the table

bgp4InternalTable set

Sets the configuration of the bgp4InternalTable in IxHAL for the port selected with the bgp4Server select command, by reading the configuration option values set by the bgp4InternalTable config option value command. Specific errors are:


bgp4InternalTable setDefault



SEE ALSO bgp4Server, bgp4ExternalTable, bgp4InternalNeighborItem, bgp4ExternalNeighborItem, bgp4RouteItem


bgp4RouteItem

NAME - bgp4RouteItembgp4RouteItem - configure a route item, with attributes, to be associated with BGP neighbors.

SYNOPSIS bgp4RouteItem sub-command options

DESCRIPTION The bgp4RouteItem holds a route range that is associated with a bgp4InternalNeighborItem / bgp4ExternalNeighborItem. This command defines a set of routes and associated attributes. One attribute is supplied by a subsidiary command: bgp4ASPathItem, whose elements are included as a list associated with bgp4RouteItem. Refer to “BGP4” on page 3-19 for a discussion on BGP4 testing with Ixia equipment. Refer to “bgp4RouteItem” on page 5-55 for an over-view of this command. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

aggregatorASNum The AS associated with the aggregator router ID in the AGGREGATOR attribute. (default = 0)

aggregatorIDMode Causes the AS field to be incremented for each neighbor session generated for the range of neighbor addresses in the AGGREGATOR attribute. (default = 1)

aggregatorIpAddress The IP address of the router that aggregated two or more routes in the AGGREGATOR attribute. (default = 0.0.0.0)

asPathSetMode Determines the handling of the Local AS# in generated AS sequences and sets and AS Confederation Sequences and Sets. The options are:

clusterList A list of clusters that a particular route has passed through; associated with the CLUSTER attribute. Expressed as a TCL list {...}. (default = { })

communityList A list of communities associated with the route entry; associated with the COMMUNITY attribute. (default = { })

Option Value Usage

bgpRouteAsPathNoInclude

0 Do not include the Local AS#. When the route item is associated with an Internal router, this is only option available–and must be set in a bgp4RouteItem config -asPathSetMode 0.

bgpRouteAsPathIncludeAsSeq

1 (default) Include the Local AS# in the AS Path Sequence only.

bgpRouteAsPathIncludeAsSet

2 Include the Local AS# in the AS Path Set only.

bgpRouteAsPathIncludeAsSeqConf

3 Include the Local AS# in the AS Path Confederation Sequence only.

bgpRouteAsPathIncludeAsSetConf

4 Include the Local AS# in the AS Path Confederation Sequence only.


bgp4RouteItemA

enableAggregator Generates an AGGREGATOR attribute using the aggregatorIpAddress, aggregatorASNum, and aggregatorIDMode. (default = 0)

enableASPath Enables the generation of AS Path related items (AsSet, AsSequence, AsConfedSet and AsConfedSequence) based on information added from the bgp4AsPathItem. (default = 0)

enableAtomicAggregate

Sets the attribute bit that indicates that the router has aggregated two or more prefixes in the AGGREGATOR attribute. (default = 0)

enableCluster Enables the generation of the CLUSTER attribute list based on information in clusterList. (default = 0)

enableCommunity Enables the generation of a COMMUNIITY attribute list based on information in communityList. (default = 0)

enableGenerateUniqueRoutes

When set to 1, each router generates a different IP address range. a bgp4InternalNeighborItem or bgp4ExternalNeighborItem item must be configured with rangeCount > 1. When not enabled, each router will advertise the route range as is. When enabled, the first router advertises numRoutes routes starting at networkAddress, the next router advertises numRoutes routes starting at (networkAddress + numRoutes), and so on. (default = 0)

enableLocalPref Enables the generation of a LOCAL PREF attribute based on the information in localPref. This value should be set to true only for EBGP. (default = 0)

enableMED Enables the generation of a MULTI EXIT DISCRIMINATOR attribute, based on the information in MED. (default = 0)

enableNextHop Enables the generation of a NEXT HOP attribute, based on information in nextHopIpAddress and nextHopMode (default = 1)

enableOrigin Enables the generation of an ORIGIN attribute, based on information in originProtocol. (default = 1)

enableOriginatorId Enables the generation of an ORIGINATOR-ID attribute, based on information in originatorId. (default = 0)

enableRouteFlap Enables the flapping functions described by routeFlapTime, routFlapDropTime, routesToFlapFrom and routesToFlapTo. (default = 0)

enableRouteRange Enables the use of this route item as an advertised range. (default = 0)

fromPacking The minimum number of routes to pack into an UPDATE message. Random numbers are chosen from the range fromPacking to toPacking. (default = 0)

The following chart indicates the range of packing depending on the setting of this and the toPacking values:

fromPacking toPacking Packing Ranges

0 0 As many as possible

0 b Random from 1 to b

a 0 Always a routes

a b Random from a to b


bgp4RouteItem

fromPrefix The first prefix length to generate based on the networkAddress and numRanges. (default = 0)

iterationStep During prefix generation, the increment between prefixes. (default = 1)

localPref The local preference value for the routes with the LOCAL PREF attribute. (default = 0)

med The multi-exit discriminator value in the MULTI EXIT DISCRIMINATOR attribute. (default = 0)

networkAddress The network address used for the generated prefixes. (default = 0.0.0.0)

nextHopIpAddress The IP address of the next hop associated with the NEXT HOP attribute. (default = 0.0.0.0)

nextHopMode Indicates that the nextHopIpAddress will be incremented for each neighbor session generated for the range of neighbor addresses. (default = 1)

numRoutes The number of prefixes (routes) to generate for this routeItem. (default = 0)

originatorId The router that originated a particular route; associated with the ORIGINATOR-ID attribute. (default = 0.0.0.0)

originProtocol An indication of where the route entry originated. One of:

routeFlapDropTime During flapping operation, the period expressed in seconds during which the route will be withdrawn from its neighbors. (default = 0)

routeFlapTime During flapping operation, the time between flap cycles, expressed in seconds. (default = 0)

routesToFlapFrom During flapping operation, the first route prefix in a range to flap. (default = 0)

routesToFlapTo During flapping operation, the last route prefix in a range to flap. (default = 0)

thruPacking The maximum number of routes to pack into an UPDATE message. Random numbers are chosen from the range fromPacking to toPacking. See the discussion under fromPacking above. (default = 0)

thruPrefix The last prefix length to generate based on the networkAddress and numRanges. (default = 0)

COMMANDS The bgp4RouteItem command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

Option Value Usage

bgpOriginIGP 0 (default) Interior Gateway Protocol

bgpOriginEGP 1 Exterior Gateway Protocol

bgpOriginIncomplete 2 learned by some other means


bgp4RouteItemA

bgp4RouteItem addASPathItem

Adds the AS Path items specified via config option calls to the bgp4AsPath list. The AS path item must have been previously been configured through the use of the bgp4ASPathItem command. Specific errors are:

• Invalid AS path parameters

bgp4RouteItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4RouteItem command.

bgp4RouteItem clearASPathList

Clears all of the AS Path items associated with the command.

bgp4RouteItem config option valueModify the configuration options of the bgp4RouteItem. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for bgp4RouteItem.

bgp4RouteItem getFirstASPathItem

Gets the first AS path item from the list. The contents of the item are available in the bgp4ASPathItem command. Specific errors are:

• There are no items in the list

bgp4RouteItem getNextASPathItem

Gets the next AS path item in the list. The contents of the item are available in the bgp4ASPathItem command. Specific errors are:

• There are no more items in the list

bgp4RouteItem setDefault



SEE ALSO bgp4InternalTable, bgp4ExternalTable, bgp4InternalNeighborItem, bgp4ExternalNeighborItem, bgp4RouteItem


bgp4Server

NAME - bgp4Serverbgp4Server - access the BGP4 component of the Protocol Server for a particular port.

SYNOPSIS bgp4Server sub-command options

DESCRIPTION The bgp4Server command is necessary in order to access the BGP4 component of the Protocol Server for a particular port. The select sub-command must be used before all other bgp4 commands. Refer to “BGP4” on page 3-19 for a dis-cussion on BGP4 testing with Ixia equipment. Refer to “bgp4Server” on page 5-53 for an overview of this command. The optional BGP4 test package must be installed in order for this command to operate.

STANDARD OPTIONS

None.

COMMANDS The bgp4Server command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

bgp4Server cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4Server command.

bgp4Server config option valueModify the configuration options of the bgp4Server. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for bgp4Server.

bgp4Server generateStreams chasID cardID portID actionGenerate streams creates additional streams for the indicated port and replaces the port’s current streams or adds it to the current streams depending on the action option:

A separate stream is generated for each enabled route range associated with each neighbor router; each stream covers the count of IP addresses associated with the route range. The characteristics of the generated streams are:

• Each stream but the last is set to advance to the next stream; the last stream is set to return to the first stream.

• Ethernet II encapsulation is used.• IPv4 framing is used.• The transmission rate is the port’s maximum rate.• Minimum frame sizes are used.• A data pattern of incrementing bytes (00 01 02 ...) is used.

Option Value Usage

protocolServerStreamReplace 0 Replace the port’s current streams.

protocolServerStreamAppend 1 Add the streams to the port’s current streams.


bgp4ServerA

• The source MAC address is set from the value associated with the indicated sending port.

• The destination MAC address is set via an ARP lookup on the destination IP address, which is set using UDF4.

• A single burst of packets is sent per stream, with the count equal to the count of addresses in the route range.

• UDF4 or IP address control are used to iterate through the count of addresses in the route range; it should not be reprogrammed.

bgp4Server select chasID cardID portIDAccesses the BGP4 component of the Protocol server for the indicated port. Spe-cific errors are:

• No connection to the chassis• Invalid port specified

bgp4Server setDefault


EXAMPLES package req IxTclHal

# Define parameters used by BGP routerset host hiwire

# Port is chassis 1, card 1, port 1set ch 1set ca 1set po 1set pl [list [list $ch $ca $po]]set myMac {00 0a de 01 01 01}set as 100set router 198.18.1.2set neighbor 198.18.1.1set enableLinkFlap falseset update 30set linkFlapDropTime 1set linkFlapTime 10set hold 90set rangeCount 1set rangeIp 10.0.0.0set rangePrefix 16set rangeNumRoutes 1000set rangeEnableRouteFlap falseset rangeDuration 1set rangePeriod 2000set asPath {100 200 300}set localPref 10

ixInitialize $host

# Set up IP address table for others who ARP to usipAddressTableItem setDefault ipAddressTableItem config -numAddresses 1ipAddressTableItem config -mappingOption oneIpToOneMACipAddressTableItem config -overrideDefaultGateway falseipAddressTableItem config -fromIpAddress $routeripAddressTableItem config -fromMacAddress $myMacipAddressTable addItemipAddressTable set $ch $ca $po


bgp4Server

# Select port to operatebgp4Server select $ch $ca $po

# Clear external tablebgp4ExternalTable setDefaultbgp4ExternalTable clear

# Clear routes in neighborbgp4ExternalNeighborItem clearRouteList

# Make a route itembgp4RouteItem clearASPathListbgp4AsPathItem setDefaultbgp4AsPathItem config -enableAsSegment truebgp4AsPathItem config -asList $asPathbgp4AsPathItem config -asSegmentType bgpSegmentAsSequence

# With an AS pathif {[bgp4RouteItem addASPathItem]} { ixPuts “Problem adding Path $asPath” return } # And the rest of the route item settingsbgp4RouteItem setDefaultbgp4RouteItem config -networkAddress $rangeIpbgp4RouteItem config -fromPrefix $rangePrefixbgp4RouteItem config -thruPrefix $rangePrefixbgp4RouteItem config -numRoutes $rangeNumRoutesbgp4RouteItem config -enableRouteFlap $rangeEnableRouteFlapbgp4RouteItem config -routeFlapTime $rangePeriodbgp4RouteItem config -routeFlapDropTime $rangeDurationbgp4RouteItem config -enableNextHop truebgp4RouteItem config -nextHopIpAddress $routerbgp4RouteItem config -enableASPath truebgp4RouteItem config -enableRouteRange truebgp4RouteItem config -localPref $localPrefbgp4RouteItem config -enableLocalPref truebgp4RouteItem config -asPathSetMode bgpRouteAsPathIncludeAsSeq

# Add the route item to the external neighborif {[bgp4ExternalNeighborItem addRouteItem]} { ixPuts “Problem adding external route Item”}

# Define the external neighborbgp4ExternalNeighborItem setDefaultbgp4ExternalNeighborItem config -localIpAddress $routerbgp4ExternalNeighborItem config -rangeCount $rangeCountbgp4ExternalNeighborItem config -dutIpAddress $neighborbgp4ExternalNeighborItem config -keepAliveTime $holdbgp4ExternalNeighborItem config -messageTime $updatebgp4ExternalNeighborItem config -enableLinkFlap $enableLinkFlapbgp4ExternalNeighborItem config -linkFlapDropTime $linkFlapDropTimebgp4ExternalNeighborItem config -linkFlapTime $linkFlapTimebgp4ExternalNeighborItem config -enableExternalNeighbor truebgp4ExternalNeighborItem config -neighborASNum $as

# And add the neighbor to the external tableif {[bgp4ExternalTable addNeighborItem]} {


bgp4ServerA

ixPuts “Problem adding External Neighbor $router”}

# And complete the setting for the external tablebgp4ExternalTable setDefaultbgp4ExternalTable config -retries 0bgp4ExternalTable config -retryDelay 120bgp4ExternalTable config -enableActiveConnect truebgp4ExternalTable config -enableEstablishOnce falsebgp4ExternalTable set

# Let the protocol server respond to ARP, BGP and PINGprotocolServer config -enableArpResponse trueprotocolServer config -enableBgp4Service trueprotocolServer config -enablePingResponse falseprotocolServer set $ch $ca $po

# Set up for bgp4StatsQuerybgp4StatsQuery clearAllNeighborsbgp4StatsQuery clearAllStatsbgp4StatsQuery addNeighbor $neighbor $routerbgp4StatsQuery addStat bgpExternalConnectedAcceptedbgp4StatsQuery addStat bgpExternalConnectedReceived

# Send the data to the hardwareixWriteConfigToHardware pl

bgp4StatsQuery get $chassis $card $port

# Need to wait until getStat returns successfullyset timer 10for {set time 0} {$time < $timer } {incr time} { if {![bgp4StatsQuery getStat bgpExternalConnectedAccepted \

$localIpAdd $dutIpAdd]} { set accepted [bgp4StatsQuery cget -statValue]

bgp4StatsQuery setDefault

if [bgp4StatsQuery getStat bgpExternalConnectedReceived \$localIpAdd $dutIpAdd] {

set received [bgp4StatsQuery cget -statValue] } break } after 1000}

SEE ALSO bgp4InternalTable, bgp4ExternalTable, bgp4InternalNeighborItem, bgp4ExternalNeighborItem, bgp4RouteItem


bgp4StatsQuery

NAME - bgp4StatsQuerybgp4StatsQuery - gets the BGP server statistics on a port of a card on a chassis.bgpStatsQuery - also known by this name, but usage is deprecated.

SYNOPSIS bgp4StatsQuery sub-command optionsDESCRIPTION

The bgp4StatsQuery command is used to get BGP4 protocol server related sta-tistics. Specific statistics must be requested for a set of <Neighbor IP address, DUT IP address> pairs. The pairs are set up using the addNeighbor sub-com-mand, while the set of statistics desired are established with the addStat sub-command. Statistics are read from the hardware via the get sub-command, and specific statistics are made available through the getStat sub-command. The optional BGP4 test package must be installed in order for this command to oper-ate.

STANDARD OPTIONS

statName Read-only. The name of the statistic retreived.

statValue Read-only. The value of the statistic, as a string.

COMMANDS The bgp4StatsQuery command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

bgp4StatsQuery addNeighbor neighborIPAddress dutIPAddressAdds a new neighbor-DUT address pair to the table of statistics to be fetched. Specific errors are:

• Invalid IP address(es)

bgp4StatsQuery addStat statIDAdds a new statistic to the table of statistics to be fetched. See the getStat com-mand for a list of statIDs. Specific errors are:

• Invalid statID.

bgp4StatsQuery cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the bgp4StatsQuery command.

bgp4StatsQuery clearAllNeighbors

Deletes all neighbor-DUT address pairs from the table of statistics to be fetched.

bgp4StatsQuery clearAllStats

Deletes all statistics from the table of statistics to be fetched. See the getStat command for a list of statIDs.


bgp4StatsQueryA

bgp4StatsQuery delNeighbor neighborIPAddress dutIPAddressDeletes a neighbor-DUT address pair from the table of statistics to be fetched. Specific errors are:

• The neighbor pair could not be found in the list

bgp4StatsQuery delStat statIDDeletes a statistic from the table of statistics to be fetched. See the getStat com-mand for a list of statIDs.

bgp4StatsQuery get chasID cardID portIDThis command causes the statistics associated with the indicated port to be fetched from the Protocol Server. It may be followed by one or more calls to bgp4StatsQuery getStat.

bgp4StatsQuery getStat statID neighborIPAddress dutIPAddressGets the statistics counter of type statID which may be one of the items from the table below. This must be preceded by a call to bgp4StatsQuery get. The first call to this command following a call to bgp4StatsQuery get must wait for a return value before preceding. The actual value of the statistics may be obtained via calls to bgp4StatsQuery cget statName and statValue. Additional statistics may be obtained by calling bgp4StatsQuery getStat again.

statID Usage

bgpActiveOn Indicates that enableActiveConnect is on. See bgp4ExternalTable and bgp4InternalTable.

bgpCeaseReceived Ceases Received. Number of Ceases received. The Cease error code is used by a BGP peer in a Notification message to close its BGP connection. Must not be used when a fatal error exists, such as those listed here.

bgpCeaseSent Ceases Sent. Number of Ceases sent. The Cease error code is used by a BGP peer in a Noti-fication message to close its BGP connection. Must not be used when a fatal error exists, such as those listed here.

bgpErrorBadMsgLength Bad Message Length. Multiple causes for this error are if the Length field for the header is less than 19 or greater than 4096, the OPEN message is less than minimum length, the UPDATE mes-sage is less than minimum length, the KEE-PALIVE message is not equal to 19, or the NOTIFICATION message is less than minimum length.

bgpErrorBadMsgType Bad Message Type. When the Type field of the message header is unrecognized.

bgpExternalConnectsAccepted External Connects Accepted. The total number of attempted BGP connections by remote peers, in which the local system accepted the connection.

bgpExternalConnectsReceived External Connects Received. The total number of attempted BGP connections by remote peers, including accepted and rejected.


bgp4StatsQuery

bgpHeaderErrorConnNotSyncron Connection Not Synchronized. When the Marker field of the message header is not the one expected.

bgpHeaderErrorReceived Header Errors Received. Total Number of Header Errors received on this port.

bgpHeaderErrorSent Header Errors Sent. Total Number of Header Errors sent from this port.

bgpHeaderErrorsSubUnspecified Invalid Header Suberror Unspecified. If the error subcode is not defined, a zero identifies this mes-sage header error as unspecified.

bgpHoldTimeExpiredReceived Hold Timer Expireds Received. Number of Notifi-cation error messages received. For KeepAlive, Update, and/or Notification messages. If not received by the system within the time in the Hold Time field of the OPEN message. After this mes-sage is sent, the BGP connection must be closed.

bgpHoldTimeExpiredSend Hold Timer Expireds Sent. Number of Notification error messages sent. For KeepAlive, Update, and/or Notification messages. If not received by the system within the time in the Hold Time field of the OPEN message. After this message is sent, the BGP connection must be closed.

bgpHoldTimer Our Hold Timer. A 2-octet unsigned integer indi-cating the Hold Timer value, in seconds, proposed by the sender.

bgpInvalidOpenAuthenticationFail Authentication Failures Received. For messages which carry Authentication Information, if the authentication procedure fails.

bgpInvalidOpenBadBGPId Bad BGP Ids Received. When the BGP Identifier field is not syntactically correct (not a valid IP host address).

bgpInvalidOpenBadPeerAS Invalid Open with bad peer AS number. An OPEN was receives with an invalid peer AS number.

bgpInvalidOpenReceived Invalid Opens Received. Total number of Invalid Open error messages received.

bgpInvalidOpenSent Invalid Opens Sent. Total number of Invalid Open error messages received.

bgpInvalidOpenSubUnspecified Invalid Open Suberror Unspecified. If the error subcode is not defined, a zero identifies this Open message error as unspecified.

bgpInvalidOpenUnacceptHoldTime Non Acceptable Hold Times Received. The Hold Time field is not acceptable. Hold time values of 1 or 2 seconds must be rejected. Any Hold Time may be rejected by the implementation.

bgpInvalidOpenUnsupportParm Unsupported Parameters Received. When one of the optional parameters in the OPEN message is not recognized.

bgpKeepAliveReceived KeepAlives Received. Total number of KeepAlive messages received.

bgpKeepAliveSent KeepAlives Sent. Total number of KeepAlive mes-sages sent. They cannot be sent more often than 1 per second, but must be sent often enough to keep the Hold Timer from expiring.

statID Usage


bgp4StatsQueryA

bgpMesagesSent Messages Sent. Total number of Notification mes-sages sent.

bgpMessagesReceived Messages Received. Total number of all types of BGP4 messages received.

bgpNotificationReceived Notifications received. The number of BGP notifi-cation messages received.

bgpNotificationSent Notifications sent. The number of BGP notification messages sent.

bgpOpenReceived Opens Received. Total number of Open mes-sages received.

bgpOpenSent Opens Sent. Total number of Open messages sent.

bgpOurAS Our AS Number. A 2-octet unsigned integer indi-cating the Autonomous System number of the sender.

bgpOurId Our ID. A 4-octet unsigned integer for the sender’s BGP Identifier.

bgpOurIp Our IP. The sender’s IP address.

bgpPeerAS Peer AS Number. A 2-octet unsigned integer indi-cating the Autonomous System number of the BGP peer.

bgpPeerHoldTime Peer Hold Timer. A 2-octet unsigned integer indi-cating the Hold Timer value, in seconds, proposed by the BGP peer.

bgpPeerId Peer Id. A 4-octet unsigned integer for the peer’s BGP Identifier.

bgpPeerIP Peer IP. The peer’s IP address.

bgpRoutesAdvertised Routes Advertised. Total number of BGP routes advertised.

bgpRoutesAdvertisedReceived Routes Received. Total number of BGP routes received.

bgpRoutesPerSecondReceived Routes Received per Second. Number of BGP routes received per second.

bgpRoutesPerSecondSent Routes Sent per Second. Number of BGP routes sent per second.

bgpRoutesWithdrawn Routes Withdrawn. Total number of BGP routes withdrawn.

bgpRoutesWithdrawnReceived Route Withdraws Received. Total number of Update messages received which have a non-empty Withdrawn Routes field.

bgpStartsOccured Starts Occurred. The number of BGP Start Events which have occurred.

bgpStateMachineErrorReceived State Machine Errors Received. Total number of State Machine Errors Received. These are errors detected by the BGP Finite State Machine.

bgpStateMachineErrorSent State Machine Errors Sent. Total number of State Machine Errors Sent. These are errors detected by the BGP Finite State Machine.

statID Usage


bgp4StatsQuery

bgpStateMachineState State Machine State. The current state of the Finite State Machine. One of:

• Idle• Connect• Active• OpenSent• OpenConfirm• Established

bgpUnspecifiedErrorReceived Unspecified Error Received. The number of errors received that are not described in RFC 1771 and amendments.

bgpUnspecifiedErrorSent Unspecified Error Sent. The number of errors sent that are not described in RFC 1771 and amend-ments.

bgpUpdateAttribLengthError Attribute Length Error. For any recognized attribute where the Attribute Length conflicts with the expected length, based on attribute type code.

bgpUpdateErrorAsPathInvalid Malformed AS_PATH. If the AS_PATH attribute is not correct syntactically.

bgpUpdateErrorASRoutingLoop AS Routing Loop. The number of AS routing loop errors received.

bgpUpdateErrorAttribFlagError Attribute Flags Error. For any recognized attribute where the Attribute Flags conflict with the Attribute Type.

bgpUpdateErrorAttribListError Malformed Attribute List. When the Unfeasible Routes Length or Total Attribute Length is too large. Also, when any attribute appear more than once in the Update message.

bgpUpdateErrorMissing-WellKnownAttrib

Missing Well-known Attribute. When any of the mandatory well-known attributes are not present.

bgpUpdateErrorNetworkFieldIn-valid

Invalid Network Field. The syntax of the Network Layer Reachability Information (NLRI) field is not correct.

bgpUpdateErrorNextHopAttribIn-valid

Invalid NEXT_HOP Attribute. The NEXT_HOP attribute field is not syntactically correct.

bgpUpdateErrorOptionalAttribError Optional Attribute Error. The number of optional attribute incorrect values received.

bgpUpdateErrorOriginAttribInvalid Invalid ORIGIN Attribute. When the ORIGIN attribute has an undefined value.

bgpUpdateErrorReceived Update Errors Received. Total number of Update errors received.

bgpUpdateErrorSent Update Errors Sent. Total number of Update errors sent.

bgpUpdateErrorSubUnspecified Invalid Update Suberror Unspecified. If the error subcode is not defined, a zero identifies this Update message error as unspecified.

bgpUpdateErrorUnknown-WellKnownAttrib

Unrecognized Well-known Attribute. If any of the mandatory well-known attributes are not recog-nized.

bgpUpdateReceived Updates Received. Total number of BGP route updates received.

bgpUpdateSent Updates Sent. Total number of BGP route updates sent.

statID Usage


bgp4StatsQueryA

Specific errors include:• No connection to a chassis• Invalid port number• A network problem has occurred

bgp4StatsQuery set chasID cardID portIDNo function is currently performed.

SEE ALSO

bgpvalidOpenUnsupportVersion Unsupported Version Received. When the Ver-sion Field contains an unsupported version num-ber.

statID Usage


capture

NAME - capturecapture - configure the capture parameters on a port of a card on a chassis.

SYNOPSIS capture sub-command options

DESCRIPTION The capture command is used to configure the capture parameters and sets up the capture buffer. The afterTriggerFilter, beforeTriggerFIlter, captureMode, continuousFilter, fullAction and triggerPosition options are associated with the circular buffer feature which is only available on some card types. Refer to the Ixia Hardware Guide for a list of which modules support the features.

STANDARD OPTIONS

afterTriggerFilter Controls the capture of data after triggering when operating in triggered mode (captureMode = captureTriggerMode). Available option values are:

beforeTriggerFilter Controls the capture of data prior to triggering when operating in triggered mode (captureMode = captureTriggerMode). Available option values are:

captureMode Controls whether data capture is performed in a continuous or triggered mode. Available option values are:

continuousFilter Controls whether data captured in continous mode (captureMode = captureContinuousMode) is filtered or not. Available option values are:

Option Value Usage

captureAfterTriggerAll 0 capture all data after trigger.

captureAfterTriggerFilter

1 (default) capture filtered data after trigger using filter settings.

captureAfterTriggerConditionTrigger

2 capture filtered data after trigger using trigger set-tings, as opposed to filter settings.

Option Value Usage

captureBeforeTriggerAll 0 (default) capture all data before trigger.

captureBeforeTriggerNone

1 capture none of the data before trigger.

captureBeforeTriggerFilter

2 capture filtered data before trigger as per the filter settings.

Option Value Usage

captureContinuousMode

0 capture data in the buffer continuously, regardless of trigger settings. Data may be filtered; see continu-ousFilter.

captureTriggerMode 1 (default) capture data only after triggered.

Option Value Usage

captureContinuousAll 0 (default) capture all data, regardless of filter settings.

captureContinuousFilter 1 capture only filtered data, as per filter settings.


captureA

enableSmallPacketCapture true/false

Applies to OC12 cards only. Capture of packets of 48 bytes or less at full wire rates can be problematic and is usually treated as an error. This setting allows packets of 48 bytes or less in length to be captured. The data captured, however, may be corrupt. (default = false)

fullAction Controls the action of the buffer when it reaches the full status. Available option values are:

nPackets Read-only. Number of packets available or captured in the capture buffer.

sliceSize The maximum number of octets of each frame that will be saved in this capture buffer. For example, if a 1500 octet frame is received by the probe and this option is set to 500, then only 500 octets of the frame will be stored in the associated capture buffer. If this option is set to 0, the capture buffer will save as many octets as is possible. (default = 8191)

triggerPosition Controls the dividing line within the capture buffer between before trigger data and post trigger data. This control is only useful in triggered mode (captureMode = captureTriggerMode) and before trigger capture enabled (beforeTriggerFilter = captureBeforeTriggerAll or captureBeforeTriggerFilter). TriggerPosition is expressed as a percentage of the total buffer size. The beginning of the buffer with this percentage is used in a wrap-around mode for before trigger data and the remainder is filled up with triggered data. (default = 1.0)

DEPRCATEDSTANDARD OPTIONS

filter

sliceOffset

trigger

COMMANDS The capture command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

capture cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the capture command.

capture config option valueModify the configuration options of the capture. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for capture.

Option Value Usage

lock 0 (default) after the buffer is full, do not capture any more frames

wrap 1 when the buffer is full, start storing the new frames at the beginning of the buffer over-writing the previously stored frames


capture

capture get chasID cardID portIDGets the current configuration of the capture for port with id portID on card car-dID, chassis chasID. from its hardware. Call this command before calling cap-ture cget option value to get the value of the configuration option. Specific errors are:


capture set chasID cardID portIDSets the configuration of the capture in IxHAL for port with id portID on card cardID, chassis chasID by reading the configuration option values set by the cap-ture config option value command. Specific errors are:


capture setDefault


capture write chasID cardID portIDWrites or commits the changes in IxHAL to hardware for the capture related parameters on port with id portID on card cardID, chassis chasID. Before using this command, use the capture set. Specific errors are:



# Connect to chassis and get chassis IDset host 400-031561ixInitialize $hostset chas [ixGetChassisID $host]

# Assume that there’s a four port 10/100 TX card in this slot# with port 1 looped to port 2set card 1set portlist [list [list $chas $card 1] [list $chas $card 2]]set txPortList [list [list $chas $card 1]]set rxPortList [list [list $chas $card 2]]

# Reset Ports for Factory Defaults Stream Mode / Captureport setFactoryDefaults $chas $card 1port setFactoryDefaults $chas $card 2port setDefaultport set $chas $card 1port set $chas $card 2

# The number of frames to get in the capture buffer at one timeset frameSlice 10

# Put the time in the outbound streamstream setDefaultstream config -sa {00 de ad be ef 00}stream config -da {00 ba be fa ce 00}


captureA

stream config -dma stopStreamstream config -numFrames 50000stream config -fir truestream set $chas $card 1 1ixWritePortsToHardware portlist

# Wait for Linkafter 1000ixCheckLinkState portList

ixClearStats rxPortListixStartCapture rxPortListixStartTransmit txPortList

# Get the number of frames capturedcapture get $chas $card 2set numFrames [capture cget -nPackets]ixPuts “$numFrames frames captured”

# Only look at the first 100 framesif {$numFrames > 100} {set numFrames 100}ixPuts “Frame\tTime\t\tLatncy\tData”

# Go through all of the frames $frameSlice frames at a timefor {set frameNo 1} {$frameNo <= $numFrames} {incr frameNo $frameSlice} { set lastFrame [expr $frameNo + $frameSlice - 1] if {$lastFrame > $numFrames} {$lastFrame = $numFrames}

# Get the batch of frames captureBuffer get $chas $card 2 $frameNo $lastFrame set numCaptured [expr $lastFrame - $frameNo +1]

# Go through each of the frames in the capture buffer starting at 1 for {set i 1} {$i < $numCaptured} {incr i} { # Note that the frame number starts at 1 captureBuffer getframe $i

# Get the actual frame data set data [captureBuffer cget -frame] # We’ll only look at the first bunch of bytes set data [string range $data 0 50] # Get timestamp and latency too set timeStamp [captureBuffer cget -timestamp] set latency [captureBuffer cget -latency] ixPuts -nonewline [expr $frameNo + $i] ixPuts -nonewline “\t$timeStamp” ixPuts -nonewline “\t$latency” ixPuts “\t$data” } }

SEE ALSO captureBuffer


captureBuffer

NAME - captureBuffercaptureBuffer - view the capture frames in the captured buffer.

SYNOPSIS captureBuffer sub-command options

DESCRIPTION After the capture command is used to configure the capture buffer, the capture-Buffer command is used to get a range of frames from the capture buffer. Jitter values will only be calculated on those frames that meet the constraint criteria. Two different types of constraint criteria are available; ethernet type and frame-size. For example, if the user wants to calculate jitter only on 64 byte frames, then the framesize option must be set to 64 and the enableFramesize option set to true.

STANDARD OPTIONS

averageDeviation Read-only. 64-bit value. The average deviation of the average latencies calculated by the command captureBuffer getStatistics.

averageLatency Read-only. 64-bit value. The average latency calculated by the command captureBuffer getStatistics.

enableEthernetType true/false

Enables the constraint used to calculate jitter statistics. If enabled, jitter will be calculated only for frames whose frame type field matches the ethernet type set by the option ethernetType. Does not apply unless the command captureBuffer setConstraint is applied. (default = false)

enableFramesize true/false

Enables this constraint used to calculate jitter statistics. If enabled, jitter will be calculated only for frames whose size matches the framesize set by the command option framesize. Does not apply unless the command captureBuffer setConstraint is applied. (default = false)

enablePattern true/false

Constrain the jitter statistics calculations to frames in the capture buffer that match the ethernet pattern set by this option. Does not apply unless captureBuffer setConstraint is applied. (default = false)

ethernetType Constrain the jitter statistics calculations to frames in the capture buffer that match the ethernet type set by this option. A value such as {08 00} would be appropriate. Does not apply unless option enableEthernetType is set to true and captureBuffer setConstraint is applied. (default = ““)

fir Read-only. The frame identity record.

frame Read-only. The contents of the selected frame based on the sliceSize parameter set by the capture command.

framesize Constrain the jitter statistics calculations to frames in the capture buffer whose frame size matches the value set by this option. Does not apply unless the option enableFramesize is set to true and captureBuffer setConstraint is applied. (default = 64)


captureBufferA

latency Read-only. 64-bit value. The frame latency, calculated as the difference between the transmit time and receive time of the frame, in nanoseconds.

length Read-only. The total length of the frame, regardless of the actual number of bytes in the capture buffer.

maxLatency Read-only. 64-bit value. The maximum frame latency calculated by the command captureBuffer getStatistics.

minLatency Read-only. 64-bit value. The minimum frame latency calculated by the command captureBuffer getStatistics.

numFrames Read-only. The number of frames (or slices, a slice could contain a whole frame or a part of a frame) in the capture buffer. When captureBuffer setConstraint is called this value is updated with the number of frames for each constraint.

pattern Enables this constraint used to calculate jitter statistics. If enabled, jitter will be calculated only for frames whose pattern matches the pattern in the frame at the offset set by the command option patternOffset. A value of the form {11 12 02 44} would be approprite. Does not apply unless the command captureBuffer setConstraint is applied. (default = ““)

patternOffset Used in conjunction with the pattern command. Does not apply unless the command captureBuffer setConstraint is applied. (default = 12)

standardDeviation Read-only. 64-bit value. The standard deviation of the average latencies calculated by the command captureBuffer getStatistics.

status Read-only. The status of the frame. Available status includes:

Option Value Usage

capNoErrors 0 captured frame has no error

capBadCrcGig 1 captured frame has a bad or missing CRC (gigabit only)

capSymbolErrorsGig 2 captured frame has symbol error (gigabit only)

capBadCrcAndSymbolGig 3 captured frame has a bad or missing CRC and symbol error (gigabit only)

capUndersizeGig 4 captured frame is undersize (gigabit only)

capBadCrcAndUndersizeGig 5 captured frame has a bad or missing CRC and is undersize (gigabit only)

capBadCrcAndSymbolAndUndersizeGig

7 captured frame has a bad or missing CRC and is undersize (gigabit only)

capOversizeGig 8 captured frame is oversize with a valid CRC (gigabit only)

capBadCrc 65 captured frame has a bad or missing CRC

capBadCrcAndSymbolError 67 captured frame has a bad or missing CRC and symbol error

capUndersize 68 captured frame is undersize

capFragment 69 captured frame is a fragment

capOversize 72 captured frame is oversize with a valid CRC

capOversizeAndBadCrc 79 captured frame is oversize with a bad or miss-ing CRC


captureBuffer

timestamp Read-only. 64-bit value. The arrival time of the captured frame in nanoseconds.

DEPRICATED OPTIONS

sliceOffset

COMMANDS The captureBuffer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

captureBuffer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the captureBuffer command.

captureBuffer clearConstraint

Clears the constraints used to calculate the average, standard deviation and aver-age deviation of the latencies of the captured frames in the capture buffer. Statis-tics will be calculated on the entire buffer.

captureBuffer config option valueModify the configuration options of the captureBuffer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for captureBuffer.

captureBuffer export fileNameExports the current contents of the capture buffer from the last captureBuffer get command to the file indicated in fileName. The format of the file is dictated by the extension on the file (only the .cap and .enc file format is supported):

capDribble 80 captured frame has a dribble error

capAlignmentError 81 captured frame has alignment error (10/100 only)

capAlignAndSymbolError 83 captured frame has alignment and symbol error

capGoodFrame 192 captured frame is a valid frame with no errors (default)

capBadCrcAndGoodFrame 193 captured frame has a bad or missing CRC but otherwise valid frame

capErrorFrame 255 captured frame has a general error other than one of the specified errors in this list

Option Value Usage

.txt a text file suitable for import into a database.

.cap a binary format for use with the captureBuffer import function or IxExplorer’s File Import function.


captureBufferA

captureBuffer get chasID cardID portID fromFrame toFrameGets the group of captured frames from the capture buffer for chasID cardID portID, beginning with frame fromFrame through frame and puts it into local memory. Call this command before calling captureBuffer getframe frameNum to get the capture buffer from hardware. The capture cget –nPackets should be called before this command to determine how many frames are available in the capture buffer.

captureBuffer getConstraint

Gets the constraints used to calculate the average, standard deviation and average deviation of the latencies of the captured frames in the capture buffer retrieved by captureBuffer get.

captureBuffer getframe frameNumGets the capture buffer data from local memory for frameNum. Call captureBuffer get chasID cardID portID fromFrame toFrame before calling this command.

captureBuffer getStatistics

Calculates the average, standard deviation and average deviation of the latencies of the captured frames in the capture buffer retrieved by captureBuffer get.

captureBuffer import fileName chasID cardID portIDImports a file into the capture buffer indicated by chasID cardID portID from the file indicated in fileName. The format of the file is dictated by the extension on the file:

.cap – a binary format generated by the captureBuffer export function or IxExplorer’s File Export function.

.enc – a binary format for use with NAI’s Sniffer program.

captureBuffer setConstraint

Sets the constraints used to calculate the average, standard deviation and average deviation of the latencies of the captured frames in the capture buffer retrieved by captureBuffer get.

captureBuffer setDefault


EXAMPLES See examples under capture.

SEE ALSO capture

.enc a binary format for use with NAI’s Sniffer program.Note that when working with POS ports, the export function maps the POS frames to look like Ethernet data: the POS header is stripped off (4 bytes), the MAC address is padded out to 12 bytes with zeroes, a packet type identifier of 0x0800 (2 bytes, Ethernet) is added and the beginning of the MAC DA is over-written with the POS header.


card

NAME - cardcard - get version and type of card.

SYNOPSIS card sub-command options

DESCRIPTION This command allows the user to view version and type information for the card.

STANDARD OPTIONS

clockRxRisingEdge For 10/100 RMII cards, received data is to be clocked on the rising edge. (default = 1)

clockTxRisingEdge For 10/100 RMII cards, xmit data is to be clocked on the rising edge. (default=1)

fpgaVersion Read-only. The current version of central FPGA image file on this card.

hwVersion Read-only. The current hardware version of this card.

portCount Read-only. Number of ports on this card; if no card present, returns 0.

serialNumber Read-only. For load modules which possess a serial number, this is the serial number associated with the load module.

type Read-only. The type of the card selected. Options include:

Option Value Usage

cardNone 0 No card present

card101004port 2 4 port 10/100 card

cardGigabit2Port 3 2 port gigabit card

card10100Mii 4 10/100 MII card

card10100RMii 5 10/100 Reduced MII card

card100FxMultiMode 6 10/100 FX multi-mode card

cardGbic 7 2 port GBIC card

cardPOS2Port 8 2 port POS card - OC12c/OC3c

cardPosOc48 9 1 port POS card

card10100Level3 10 4 port 10/100 level 3 card

cardGigabitLevel3 11 2 port gigabit level 3 card

cardGbicLevel3 12 2 port level GBIC card

cardGigCopper 13 2 port gigabit over copper card

cardGigCopperLevel3 14 2 port level gigabit over copper card

cardGigabitGmii 17 2 port Gigabit GMII

cardPosOC48Level3 18 1 port POS level 3 card

cardUSB 19 4 port 10 Mbps/USB card

cardPosOc192Fob2 20 2 port POS level 3 OC 192 Fiber Optic Board

cardPosOc192Fob1 21 1 port POS level 3 OC 192 Fiber Optic Board

cardPosOc192Plm2 22 2 port POS OC 192 Fiber Optic Board


cardA

typeName Read-only. The name corresponding to the card type. One of the symbolic values shown under type.

COMMANDS The card command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

card config option valueModify the configuration options of the card. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for card.

card cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the card command.

card export fileName chasID cardIDExports the current configuration of the card at slot cardID, chassis chasID into the file named fileName. If no extension is used in fileName, a “.crd” will be added to the name. The file produced by this command may be used by the import sub-command. Specific errors are:

• No connection to a chassis• Invalid card

cardPosOc192Plm1 23 1 port POS OC 192 Fiber Optic Board

cardPosOc3 25 2 port POS OC 3 card

card100FxSingleMode 26 4 port 100 FX single-mode card

cardPosOc48VariableClocking 27 1 port POS card, variable clocking support

cardGigCopperTripleSpeed 28 2 port 10/100/1000 Copper card

cardGigSingleMode 29 2 port 1000 SX Single-mode

card10100Sh4 32 4 port 10/100 card

cardOc48Bert 36 1 port OC 48 card, Bit Error Rate Testing Only

cardOc48PosAndBert 37 1 port OC 48 card, POS and Bit Error Rate Testing

card10GigWanPlm2 38 2 port 10 Gigabit WAN card

card10GigWanPlm1 39 1 port 10 Gigabit WAN card

card10GigLanXgmiiPlm1 42 1 port 10 Gigabit LAN XGMII card

card10GigLanXuaiPlm1 46 1 port 10 Gigabit LAN XUAI card

card10100Txs48 56 48 port large form factor 10/100 card

card10100Txs8 57 8 port 10/100 card

card10GigLanXsbiPlm1 61 1 port 10 Gigabit LAN XSBI card

card10100TX2 67 2 port 10/100 card

cardGbicSp 68 1 port GBIC card

Option Value Usage


card

card get chasID cardIDGets the current configuration of the card at slot cardID, chassis chasID. Call this command before calling card cget option value to get the value of the configura-tion option. If the card does not exist, an error is returned.

card getInterface chasID cardIDGets the interface type of the card. This command returns one of the following values:

card import fileName chasID cardIDImports a saved card configuration found in the file fileName into the current configuration of the card at slot cardID, chassis chasID. If no extension is used in fileName, a “.crd” will be added to the name. The file used by this command must have been produced by the export sub-command. Specific errors are:

• No connection to a chassis• Invalid card• The card is owned by another user• fileName does not exist

card set chasID cardIDSets the current configuration of the card at slot cardID, chassis chasID by read-ing the configuration option values set by the card config option value com-mand. Specific errors are:

• No connection to a chassis• Invalid parameters• Network problem between the client and chassis

card setDefault




# Set up an array of interface type namesset interfaceTypes($::interface10100) “10/100”set interfaceTypes($::interfaceGigabit) “Gigabit”set interfaceTypes($::interfacePacketOverSonet) “OC3/OC12”set interfaceTypes($::interfaceOc48) “Oc48”set interfaceTypes($::interfaceOc192) “Oc192”set interfaceTypes($::interfaceUSB) “USB”set interfaceTypes(0) “Unknown”

interfaceUnknown 0

interface10100 1

interfaceGigabit 2

interfacePacketOverSonet 3 for OC3 and OC12

interfaceOc48 4

interfaceOc192 5

interfaceUSB 6


cardA

# Get the chassis’ number of cardschassis getFromID $chasset ncards [chassis cget -maxCardCount]ixPuts “Chassis $chas, $ncards cards”

for {set i 1} {$i <= $ncards} {incr i} { # Check for missing card if {[card get $chas $i] != 0} {

continue } set portList [list [list $chas $i 1]]

# Get all of the card’s characteristics set fpgaVersion [card cget -fpgaVersion] set hwVersion [card cget -hwVersion] set portCount [card cget -portCount] set type [card cget -type] set typeName [card cget -typeName] set interface [card getInterface $chas $i]

# And list them ixPuts “Card $i: $typeName ($type), $portCount ports, \ interface $interfaceTypes($interface), fpga $fpgaVersion, hwVersion $hwVersion”

# If the card is a 10/100 RMII, play with its settable parameters if {$type == $::card10100RMii} { card config -clockRxRisingEdge 0 card config -clockTxRisingEdge 1

card set $chas $i ixWriteConfigToHardware portList

}

# Just for fun, we’ll export the data associated with the first card # and restore it to any other cards of the same type if {$i == 1} { if {[card export cardfile $chas $i] != 0} { ixPuts “Could not export”

} else { set savedType $type

} } elseif {$type == $savedType} {

if {[card import cardfile $chas $i] == 1} { ixPuts “Could not import”

} else { # After import we need to do a set and then write to

hardware card set $chas $i ixWriteConfigToHardware portList }

}}

SEE ALSO chassis, port


chassis

NAME - chassischassis - add a new chassis to the chain and configure it.

SYNOPSIS chassis sub-command options

DESCRIPTION The chassis command is used to add a new chassis to a chain of chassis, config-ure an existing chassis or delete an existing one from the chain in use.

STANDARD OPTIONS

cableLength Specifies the length of the cable between all chassis. Options include:

id ID number given to the chassis. (default = 0)

ipAddress Read-only. The IP address associated with the chassis.

master true/false Read-only. Specifies whether this chassis is a master of a slave in a chain. There can be only one master chassis in a chain. NOTE: The master is automatically assigned based on cable connections. (default = false)

maxCardCount Read-only. Number of card can be installed on the chassis.

name The given name of the chassis. (default = defaultChassis)

operatingSystem Read-only. The operating system loaded on the chassis. One of:

sequence Specifies the sequence number of the chassis in the chain. The master must have a sequence number of 1 and other chassis should be incrementing. (default = 1)

Option Value Usage

cable3feet 0 default

cable6feet 1

cable9feet 2

cable12feet 3

cable15feet 4

cable18feet 5

cable21feet 6

cable24feet 7

Option Value Usage

chassisOSUnknown 0 Unknown operating system

chassisOSWin95 1 Windows 95

chassisOSWinNT 2 Windows NT

chassisOSWin2000 3 Windows 2000


chassisA

type Read-only. Specifies the type of chassis. Possible values are:

typeName Read-only. The printable chassis type name.

COMMANDS The chassis command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

chassis add sIPAddrAdds a new chassis with sIPAddr (hostname or IP address) to the chain. Specific errors are:

• Error connecting to the chassis (timeout, invalid IP or hostname, or invalid port) (1)

• Version mismatch (2)• The version was successfully negotiated, but a timeout occurred receiving the

chassis configuration (3)

chassis cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the chassis command.

chassis config option valueModify the configuration options of the chassis. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for chassis.

chassis del sIPAddrDeletes the chassis with sIPAddr (hostname or IP address) from the chain.

chassis get sIPAddrGets the current configuration of the chassis with sIPAddr (hostname or IP address) from hardware. Call this command before calling chassis cget option value to get the value of the configuration option. Specific errors are:


Option Value Usage

ixia1600 2 16 card chassis type



ixia100 5 1 card chassis type with GPS

ixia400C 6 1 card chassis with additional power and fans

ixia1600T 7 16 card chassis type with additional power and fans

ixiaDemo 9 128 card chassis type used in demo server

ixiaOptIxia 10 Optixia chassis

ixiaOpixJr 11 Ixia test board


chassis

chassis getFromID chasIDGets the current configuration of the chassis with chasID from hardware. Call this command before calling chassis cget option value to get the value of the con-figuration option.

chassis reboot chasIDReboots the chassis. Specific errors are:

• No connection to a chassis• Network problem between the client and chassis

chassis refresh chasIDEnsures that the data displayed it up to date. Specific errors are:


chassis resetHardware chasIDResets the hardware by initializing all the registers and statistic counters. Specific errors are:


chassis set sIPAddrSets the configuration of the chassis in IxHAL with sIPAddr (hostname or IP address) by reading the configuration option values set by the chassis config option value command. Specific errors are:


chassis setDefault


chassis setFactoryDefaults sIPAddrSets the factory default values on the chassis. Specific errors are:


chassis shutdown chasIDShuts down the chassis. Specific errors are:


chassis write chasID cardID portIDNote: This command is being phased out; please use ixWriteConfigToHardware instead.Writes or commits the changes in IxHAL to hardware for each port with portID on card cardID of chassis with ID chasID. Before using this command, use the set commands for streams, capture and filter parameters on each port. This com-mand will not write Mii related parameters (such as speed, duplex mode, autone-gotiation, and flow control) of the port. The advantage of using this command is that the whole port related configuration can be written into hardware at one time


chassisA

instead of writing into hardware for each stream, capture and filters on each port. Specific errors are:


chassis writeAll chasIDNote: This command is being phased out; please use ixWriteConfigToHardware instead.Writes or commits the changes in IxHAL to hardware for all ports of chassis with ID chasID. Before using this command, use the set commands for streams, cap-ture and filter parameters on each port. This command will not write Mii related parameters (such as speed, duplex mode, autonegotiation, and flow control) of the port. The advantage of using this command is that the whole chassis- related configuration can be written into hardware at one time instead of writing into hardware for each port.


# Set up two chassis in a chainset host1 galaxyset host2 localhost

# Remove all of the chassis in the chainchassisChain removeAll

ixInitialize [list $host1 $host2]

# Check for a valid chainif [chassisChain validChain] { ixPuts “Chain has no master”}

set masterSlave(0) slaveset masterSlave(1) master

# Get the type and capabilities of the chassischassis get $host1set chas1 [chassis cget -id]set type [chassis cget -type]

ixPuts -nonewline “Chassis $host1 (id $chas1) is type: “switch $type \ $::ixia1600 {ixPuts -nonewline “IXIA 1600”} \ $::ixia200 {ixPuts -nonewline “IXIA 200”} \ $::ixia400 {ixPuts -nonewline “IXIA 400”} \ $::ixia100 {ixPuts -nonewline “IXIA 100”} \ $::ixia400C {ixPuts -nonewline “IXIA 400C”} \ $::ixia1600T {ixPuts -nonewline “IXIA 1600T”} \ $::ixiaDemo {ixPuts -nonewline “IXIA Demo”} \ $::ixiaOptIxia {ixPuts -nonewline “IXIA OptIxia”} \ $::ixiaOpixJr {ixPuts -nonewline “IXIA OpixJr”} \ default {ixPuts -nonewline “Unknown”}

set maxCards [chassis cget -maxCardCount]ixPuts “, which can accommodate $maxCards cards”


chassis

# Add a chassis as the masterchassis setDefaultchassis config -id $chas1chassis config -sequence 1chassis add $host1

# And give it a name after the factchassis config -name “test-chassis”chassis set $host1chassis writeAll $host1

# Make sure it’s the masterchassis getFromID $chas1set master [chassis cget -master]ixPuts “$host1 is $masterSlave($master)”

chassis get $host2set chas2 [chassis cget -id]chassis setDefaultchassis config -id $chas2chassis config -sequence 2chassis config -cableLength cable6feetchassis add $host2

# Make sure it’s not the masterchassis getFromID $chas2set master [chassis cget -master]ixPuts “$host2 is $masterSlave($master)”

# Release the chassischassis del $host1chassis del $host2

SEE ALSO


chassisChainA

NAME - chassisChainchassisChain - configure an entire chassis chain

SYNOPSIS chassisChain sub-command options

DESCRIPTION The chassisChain command is used to write configuration parameters to all chassis in the chain.

STANDARD OPTIONS

delayChassisStartTime The number of seconds to delay test application after a start.(default = 5)

COMMANDS The chassisChain command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

chassisChain broadcastTopology

After a chassis is added to or deleted from a chain, it must broadcast its existence to the rest of the chassis in the chain. NOTE: This command doesn’t return a value.

chassisChain cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the chassisChain command.

chassisChain config option valueModify the configuration options of the chassisChain. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for chassisChain.

chassisChain get chasIDGets the current configuration of the chassisChain with chasID from hardware. Call this command before calling chassisChain cget option value to get the value of the configuration option.

chassisChain set

Sets the Chassis Chain configuration by reading the configuration option values set by the chassisChain config option value command.

chassisChain setDefault


chassisChain removeAll

Removes or disconnects from all the chassis in the chain.


chassisChain

chassisChain validChain

Verify whether the chain is valid. A valid chain has at least one chassis assigned as a master. Specific errors are:

• There is no master in the chain

chassisChain write groupIDWrites or commits the changes in IxHAL to hardware for every chassis that is a member of groupID. Before using this command, use the set commands for streams, capture and filter parameters on each port. The advantage of using this command is that the entire chassis chain configuration can be written into hard-ware at one time instead of writing into hardware for each stream, capture and fil-ters on each port. Specific errors are:

• A port group with the specified groupID has not been created• Network problem between the client and chassis

EXAMPLES See examples under chassis

SEE ALSO chassis, portGroup


collisionBackoffA

NAME - collisionBackoffcollisionBackoff - configure the collision backoff parameters for 10/100 ports

SYNOPSIS collisionBackoff sub-command options

DESCRIPTION The collisionBackoff command is used to configure the parameters for collision backoff operations for 10/100 ports.

STANDARD OPTIONS

collisionConstant Each successive retry operates by selecting a time slot over a range that doubles with each retry (2, 4, 8, ... 1024). This value controls the maximum number of time slots used. The values are powers of 2 from 0 through 1024. (default = 10)

continuousRetransmit true / false

If set, when a collision occurs, continuously retransmit the packet until the maxRetryCount is exhausted. (default = false)

maxRetryCount The maximum number of retries for each packet. (default = 16)

random true / false If set, when a collision occurs, wait a random amount of time before retrying the transmission. The maxRetryCount and collisionConstant values govern how often and long retries will be attempted. (default = true)

COMMANDS The collisionBackoff command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

collisionBackoff cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the collisionBackoff command.

collisionBackoff config option valueModify the Collision Backup configuration options of the port. If no option is specified, returns a list describing all of the available Collision Backoff options (see STANDARD OPTIONS) for port.

collisionBackoff get chasID cardID portIDGets the current Collision Backoff configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling collisionBackoff cget option value to get the value of the configuration option.

collisionBackoff setDefault


collisionBackoff set chasID cardID portIDSets the Collision Backoff configuration of the port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the colli-sionBackoff config option value command.

EXAMPLES See examples under forcedCollisions

SEE ALSO forcedCollisions


dataIntegrity

NAME - dataIntegritydataIntegrity - configure the Data Integrity parameters.

SYNOPSIS dataIntegrity sub-command options

DESCRIPTION The dataIntegrity command is used to configure the parameters for Data Integ-rity operations for Gigabit and OC-12/OC-48 ports. Data integrity values are additional checksums taken over a subset of a packet. In order for data integrity to operate, receiveMode portRxDataIntegrity must be performed (and committed).

STANDARD OPTIONS

enableTimeStamptrue/false

For receive-mode only. Indicates that the received data integrity packets are expected to have a 48-bit timestamp before the FCS value. (default = false)

insertSignaturetrue/false

For transmit-mode only. Inserts the data integrity signature into the transmitted stream. (default = false)

signature In the transmitted packet, the signature uniquely identifies the transmitted packet as one destined for receive port data integrity filtering .. On the receive port, the signature is used to filter only those packets that have a matching signature. (default = 08 71 18 05)

signatureOffset The offset, within the packet, of the data integrity signature. (default = 40)

COMMANDS The dataIntegrity command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

dataIntegrity cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the dataIntegrity command.

dataIntegrity config option valueModify the Data Integrity configuration options of the port. If no option is speci-fied, returns a list describing all of the available Data Integrity options (see STANDARD OPTIONS) for port.

dataIntegrity getRx chasID cardID portIDGets the current receive Data Integrity configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling dataIntegrity cget option value to get the value of the configuration option. Specific errors are:



dataIntegrityA

dataIntegrity getTx chasID cardID portID streamIDGets the current transmit Data Integrity configuration of the stream with id portID on card cardID, chassis chasID, stream streamID. Call this command before calling dataIntegrity cget option value to get the value of the configura-tion option. Specific errors are:

• No connection to a chassis• Invalid port number• The stream does not exist

dataIntegrity setDefault


dataIntegrity setRx chasID cardID portIDSets the receive Data Integrity configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the dataIntegrity config option value command. Specific errors are:


dataIntegrity setTx chasID cardID portID streamIDSets the transmit Data Integrity configuration of the stream with id portID on card cardID, chassis chasID, and stream streamID by reading the configuration option values set by the dataIntegrity config option value command. After call-ing this command, the Data Integrity configuration should be committed to hard-ware using stream write or ixWriteConfigToHardware commands. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Configured parameters are not valid for this setting• The stream does not exist


# In this example we’ll use an OC12c card with port 1 (transmit) is# directly connected to port 2 (receive)

# Data integrity is transmitted with a time stamp and received and checked# by the receive port


# Assumes that card 2 is a OC12c card with ports 1 and 2 directly connectedset card 2set txPort 1set rxPort 2


dataIntegrity



# Nothing special about the portport setFactoryDefaults $chas $card $txPortport setDefaultport set $chas $card $txPort

# One port must use recovered clock and the other notsonet setDefaultsonet config -useRecoveredClock truesonet set $chas $card $txPort

# Stream: 100,000 packetsstream setDefaultstream config -numFrames 100000stream config -framesize 4148stream config -fir truestream config -dma stopStreamstream config -percentPacketRate 100stream config -rateMode usePercentRatestream set $chas $card $txPort 1

dataIntegrity setDefaultdataIntegrity config -insertSignature truedataIntegrity setTx $chas $card $txPort 1

# Set up the Receive Port

# Set the receive mode to data integrityport setFactoryDefaults $chas $card $rxPortport setDefaultport config -receiveMode portRxDataIntegrityport set $chas $card $rxPort

# This port does not use recovered clocksonet setDefaultsonet config -useRecoveredClock falsesonet set $chas $card $rxPort

# Enable receive mode DI and expect a time stampdataIntegrity setDefaultdataIntegrity config -enableTimeStamp truedataIntegrity setRx $chas $card $rxPort


# Make sure link is upafter 1000ixCheckLinkState portList

# Clear stats on receive side and start transmittingixClearPortStats $chas $card $rxPortixStartPortTransmit $chas $card $txPortafter 1000

# Wait until done


dataIntegrityA

ixCheckPortTransmitDone $chas $card $txPort

# Get the DI frames received and errorsstat get allStats $chas $card $rxPortset diFrames [stat cget -dataIntegrityFrames]set diErrors [stat cget -dataIntegrityErrors]

ixPuts “$diFrames Data Integrity Frames received, $diErrors errors”

SEE ALSO


dhcp

NAME - dhcpdhcp - configure the DHCP parameters on a stream of a port.

SYNOPSIS dhcp sub-command options

DESCRIPTION The dhcp command is used to configure the DHCP parameters. Refer to RFC 2131 and RFC 2132 for detailed descriptions of DHCP.

STANDARD OPTIONS

bootFileName Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. (default = " ")

clientHwAddr Client hardware address. (default = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00)

clientIpAddr Client IP address. Only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests. (default = 0.0.0.0)

flags Available option values are:

hops Set to zero by client. (default = 0)

hwLen Hardware address length. (default = 6)

hwType Hardware address types. Available option values are:

Option Value Usage

dhcpNoBroadcast 0 (default) Do not broadcastdhcpBroadcast 0x8000 Broadcast

Option Value Usage

dhcpEthernet10Mb 1 (default) Ethernet 10 Mb

dhcpEthernet3Mb 2 Ethernet 3 Mb

dhcpAmateur 3 Amateur radio AX.25

dhcpProteon 4 Proteon ProNET token ring

dhcpChaos 5 Chaos

dhcpIEEE 6 IEEE 802 networks

dhcpARCNET 7 ARCNET

dhcpHyperchannel 8 Hyperchannel

dhcpLanstar 9 LanStar

dhcpAutonet 10 Autonet short address

dhcpLocalTalk 11 LocalTalk

dhcpLocalNet 12 LocalNet

dhcpUltraLink 13 Ethernet

dhcpSMDS 14 SMDS


dhcpA

opCode Operation code. Available option values are:

optionCode The code field of the options section of the DHCP frame. Available codes are:

IP Layer Parameters per Host

dhcpFrameRelay 15 Frame Relay

dhcpATM1 16 ATM

dhcpHDLC 17 HDLC

dhcpFibreChannel 18 Fibre Channel

dhcpATM2 19 ATM

dhcpSerialLine 20 Serial Line

dhcpATM3 21 ATM

Option Value Usage

Option Value Usage

dhcpBootRequest 1 (default) BOOTP request

dhcpBootReply 2 BOOTP reply

Option Value Usage

dhcpPad 0 (default)

dhcpEnd 255

dhcpSubnetMask 1

dhcpTimeOffset 2

dhcpGateways 3

dhcpTimeServer 4

dhcpNameServer 5

dhcpDomainNameServer 6

dhcpLogServer 7

dhcpCookieServer 8

dhcpLPRServer 9

dhcpImpressServer 10

dhcpResourceLocationServer 11

dhcpHostName 12

dhcpBootFileSize 13

dhcpMeritDumpFile 14

dhcpDomainName 15

dhcpSwapServer 16

dhcpRootPath 17

dhcpExtensionPath 18

Option Value Usage

dhcpIpForwardingEnable 19

dhcpNonLocalSrcRoutingEnable 20

dhcpPolicyFilter 21

dhcpMaxDatagramReassemblySize 22


dhcp

IP Layer Parameters per Interface

Link Layer Parameters per Interface

TCP Parameters

Application And Service Parameters

DHCP Extensions

dhcpDefaultIpTTL 23

dhcpPathMTUAgingTimeout 24

Option Value Usage

Option Value Usage

dhcpPathMTUPlateauTable 25

dhcpInterfaceMTU 26

dhcpAllSubnetsAreLocal 27

dhcpBroadcastAddress 28

dhcpPerformMaskDiscovery 29

dhcpMaskSupplier 30

dhcpPerformRouterDiscovery 31

dhcpRouterSolicitAddr 32

dhcpStaticRoute 33

Option Value Usage

dhcpTrailerEncapsulation 34

dhcpARPCacheTimeout 35

dhcpEthernetEncapsulation 36

Option Value Usage

dhcpTCPDefaultTTL 37

dhcpTCPKeepAliveInterval 38

dhcpTCPKeepGarbage 39

Option Value Usage

dhcpNISDomain 40

dhcpNISServer 41

dhcpNTPServer 42

dhcpVendorSpecificInfo 43

dhcpNetBIOSNameSvr 44

dhcpNetBIOSDatagramDistSvr 45

dhcpNetBIOSNodeType 46

dhcpNetBIOSScope 47

dhcpXWinSysFontSvr 48

Option Value Usage

dhcpRequestedIPAddr 50


dhcpA

optionData The data in the options section of the DHCP frame. (default = { })

optionDataLength The length of the data in the options section of the DHCP frame. (default = 0)

relayAgentIpAddr Relay agent IP address, used in booting via a relay agent. (default = 0.0.0.0)

seconds Seconds elapsed since client began address acquisition or renewal process. (default = 0)

serverHostName Optional server host name, null terminated string. (default =”“)

serverIpAddr IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. (default = 0.0.0.0)

transactionID Random number chosen by client and used by the client and server to associate messages and responses between a client and a server. (default = 0)

yourIpAddr 'your' (client) IP address. (default = 0.0.0.0)

dhcpIPAddrLeaseTime 51

dhcpOptionOverload 52

dhcpTFTPSvrName 66

dhcpBootFileName 67

dhcpMessageType 53

dhcpSvrIdentifier 54

dhcpParamRequestList 55

dhcpMessage 56

dhcpMaxMessageSize 57

dhcpRenewalTimeValue 58

dhcpRebindingTimeValue 59

dhcpVendorClassId 60

dhcpClientId 61

dhcpXWinSysDisplayMgr 49

dhcpNISplusDomain 64

dhcpNISplusServer 65

dhcpMobileIPHomeAgent 68

dhcpSMTPSvr 69

dhcpPOP3Svr 70

dhcpNNTPSvr 71

dhcpWWWSvr 72

dhcpDefaultFingerSvr 73

dhcpDefaultIRCSvr 74

dhcpStreetTalkSvr 75

dhcpSTDASvr 76

Option Value Usage


dhcp

COMMANDS The dhcp command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

dhcp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the dhcp command.

dhcp config option valueModify the configuration options of the dhcp. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for arp.

dhcp decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. dhcp getOption command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• The captured frame is not a valid DHCP packet

dhcp get chasID cardID portIDGets the current configuration of the dhcp frame for port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling dhcp cget option value to get the value of the configuration option. Specific errors are:


dhcp getOption optionCodeTypeGets the option data for optionCodeType. Specific errors are:

• There is no option data for the optionCodeType.

dhcp set chasID cardID portIDSets the configuration of the dhcp in IxHAL for port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the dhcp config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port

dhcp setDefault


dhcp setOption optionCodeTypeSets the option data for optionCodeType. Specific errors are:

• The configured parameters are not valid for this port


dhcpA


# In this example we’ll generate a DHCP response packet# with a number of option fields


# Assume card to be used is in slot 1set card 1set port 1set portList [list [list $chas $card $port]]

# Put the port in loopback modeport setFactoryDefaults $chas $card $portport setDefault

# Stream: 1 packet at 1%, with framesize large enough to hold all optionsstream setDefaultstream config -numFrames 1stream config -dma stopStreamstream config -rateMode usePercentRatestream config -percentPacketRate 1stream config -framesize 512

# Set up IP: icmp with 46 byte packetip setDefaultip config -ipProtocol udpip config -totalLength 494ip set $chas $card $port

# Set up protocolprotocol setDefaultprotocol config -name ipV4protocol config -appName Dhcp

# Set up UDPudp setDefaultudp config -sourcePort bootpClientPortudp config -destPort bootpServerPortudp set $chas $card $port

# Setup DHCP with optionsdhcp setDefaultdhcp config -opCode dhcpBootReplydhcp config -hwType dhcpEthernet10Mbdhcp config -hwLen 6dhcp config -flags dhcpBroadcastdhcp config -yourIpAddr 192.168.18.154dhcp config -serverIpAddr 192.168.18.2dhcp config -clientHwAddr {01 02 03 04 05 06}

# Optionsdhcp config -optionData 255.255.255.0dhcp setOption dhcpSubnetMaskdhcp config -optionData 192.168.18.254dhcp setOption dhcpRouterdhcp setOption dhcpGatewaysdhcp config -optionData 192.168.18.2


dhcp

dhcp setOption dhcpNameServerdhcp config -optionData widgets.comdhcp setOption dhcpDomainNamedhcp set $chas $card $port

stream set $chas $card $port 1port set $chas $card $port


SEE ALSO capture, captureBuffer


filterA

NAME - filterfilter - configure the filters of a port of a card on a chassis.

SYNOPSIS filter sub-command options

DESCRIPTION The filter command is used to configure the filters and capture triggers for receiving frames on a port of a card. The incoming frames can be filtered on a combination of varying constraints, such as destination or source address, pattern matching or specific error conditions.

STANDARD OPTIONS

asyncTrigger1DA true/false

Enables or disables User Defined Statistics counter 5 to filter on the destination MAC addresses. (default = false)

asyncTrigger1Enable true/false

Enables or disables User Defined Statistics counter 5 that counts the number of frames filtered. To use this counter the stat mode has to be set to statStreamTrigger. (default = false)

asyncTrigger1Error true/false

Enables or disables User Defined Statistics counter 5 filter on the errored frames. (default = false)

asyncTrigger1FrameSizeEnable true/false

Enables or disables the frame size constraint which specifies a range of frame sizes to filter for User Defined Statistics counter 5. (default = false)

asyncTrigger1FrameSizeFrom

The minimum range of the size of frame to be filtered for User Defined Statistics counter 5. Applicable only when asyncTrigger1FramesizeEnable is set to true. (default = 64)

asyncTrigger1FrameSizeTo

The maximum range of the size of frame to be filtered for User Defined Statistics counter 5. Applicable only when asyncTrigger1FramesizeEnable is set to true. (default = 1518)

asyncTrigger1Pattern true/false

Enables or disables User Defined Statistics counter 5 to filter on the pattern. (default = false)

asyncTrigger1SA true/false

Enables or disables User Defined Statistics counter 5 to filter on the source MAC addresses. (default = false)

asyncTrigger2DA true/false

Enables or disables User Defined Statistics counter 6 to filter on the destination MAC addresses. (default = false)

asyncTrigger2Enable true/false

Enables or disables User Defined Statistics counter 6 that counts the number of frames filtered. (default = false) To use this counter the stat mode has to be set to statStreamTrigger.

asyncTrigger2Error Enables or disables User Defined Statistics counter 6 filter on the errored frames. (default = false)


filter

asyncTrigger2FrameSizeEnable true/false

Enables or disables the frame size constraint which specifies a range of frame sizes to filter for User Defined Statistics counter 6. (default = false)

asyncTrigger2FrameSizeFrom

The minimum range of the size of frame to be filtered for User Defined Statistics counter 6. Applicable only when asyncTrigger1FramesizeEnable is set to true. (default = 64)

asyncTrigger2FrameSizeTo

The maximum range of the size of frame to be filtered for User Defined Statistics counter 6. Applicable only when asyncTrigger1FramesizeEnable is set to true. (default = 1518)

asyncTrigger2Pattern true/false

Enables or disables User Defined Statistics counter 6 to filter on the pattern. (default = false)

asyncTrigger2SA true/false

Enables or disables User Defined Statistics counter 6 to filter on the source MAC addresses. (default = false)

captureFilterDA One of two available destination MAC addresses to filter on. Applicable only when capturefilternable is set to true. The possible values are:

captureFilterEnable true/false

Enables or disables the capture filter. (default = false)

captureFilterErrror Applicable only when captureFilterEnable is set to true. The possible values are:

Option Value Usage

anyAddr 0 (default) disables the destination address filter con-straint

addr1 1 sets the destination address filter constraint to trigger on frames with a destination MAC address that matches DA1and DA1mask as specified in the filter palette

notAddr1 2 sets the destination address filter constraint to trigger on all frames except those with a destination MAC address that matches DA1 and DA1 mask as speci-fied in the filter palette

addr2 3 sets the destination address filter constraint to trigger on frames with a destination MAC address that matches DA2 and DA2mask as specified in the filter palette

notAddr2 4 sets the destination address filter constraint to trigger on all frames except those with a destination MAC address that matches DA2 and DA2 mask as speci-fied in the filter palette

Option Value Usage

errAnyFrame 0 (default) disables the error filter constraint

errGoodFrame 1 sets the error filter constraint to trigger when frames with no errors are received

errBadCRC 2 sets the error filter constraint to trigger when frames with bad CRC errors are received

errBadFrame 3 sets the error filter constraint to trigger when cor-rupted frames are received


filterA

captureFilterFrameSizeEnable true/false

Enables or disables the frame size constraint which specifies a range of frame sizes to filter. (default = false)

captureFilterFrameSizeFrom

Applicable only when captureFilterFrameSizeEnable is enabled. The minimum range of the size of frame to be filtered. (default = 64)

captureFilterFrameSizeTo

Applicable only when captureFilterFrameSizeEnable is enabled. The maximum range of the size of frame to be filtered. (default = 1518)

captureFilterPattern Applicable only when capturefilternable is set to true. The possible values are:

errAlign 4 sets the error filter constraint to trigger when frames with alignment errors are received (10/100 only)

errDribble 5 sets the error filter constraint to trigger when frames with dribble errors are received (10/100 only)

errLineError 6 sets the error filter constraint to trigger when frames with line errors are received (gigabit only)

errLineAndBadCRC 7 sets the error filter constraint to trigger line errors and bad CRC are received (gigabit only)

errLineAndGoodCRC 8 sets the error filter constraint to trigger when frames with line errors and bad CRC are received (gigabit only)

errUndersize 9 sets the error filter constraint to trigger when under-sized frames (less than 64 bytes) are received

errOversize 10 sets the error filter constraint to trigger when over-sized frames (greater than 1518 bytes) are received

errFragment 11 sets the error filter constraint to trigger when frag-mented frames are received

Option Value Usage

Option Value Usage

anyPattern 0 (default) disables the pattern filter constraint

pattern1 1 sets the pattern filter constraint to trigger on frames with a pattern that matches pattern1and patternMask1 at offset patternOffset1 as specified in the filter palette

notPattern1 2 sets the pattern filter constraint to trigger on frames except those with a pattern that matches pattern1and patternMask1 at offset patternOffset1 as specified in the filter palette

pattern2 3 sets the pattern filter constraint to trigger on frames with a pattern that matches pattern2 and patternMask2 at offset patternOffset2 as specified in the filter palette

notPattern2 4 sets the pattern filter constraint to trigger on frames except those with a pattern that matches pattern2and patternMask2 at offset patternOffset2 as specified in the filter palette

pattern1AndPattern2 5 sets the pattern filter constraint to trigger on frames with a pattern that matches pattern1, pattern2 and patternMask1, patternMask2 at offset patternOffset1 and patternOffset2 as specified in the filter palette


filter

captureFilterSA One of two available destination MAC addresses to filter on. Applicable only when capturefilternable is set to true. The possible values are:

captureTriggerDA One of two available destination MAC addresses to filter on. Applicable only when captureTriggerEnable is set to true. The possible values are as in capturefilteredA. (default = 0)

captureTriggerEnable true/false

Enables or disables the capture trigger. (default = false)

captureTriggerError Applicable only when captureTriggerEnable is set to true. The possible values are as in capturefilterrror. (default = 0)

captureTriggerFrameSizeEnable true/false

Enables or disables the frame size constraint which specifies a range of frame sizes to trigger. (default = false)

captureTriggerFrameSizeFrom

Applicable only when captureTriggerFrameSizeEnable is enabled. The minimum range of the size of frame to be triggered. (default = 64)

captureTriggerFrameSizeTo

Applicable only when captureTriggerFrameSizeEnable is enabled. The maximum range of the size of frame to be triggered. (default = 1518)

captureTriggerPattern Applicable only when captureTriggerEnable is set to true. The possible values are as in captureFilterPattern. (default = 0)

captureTriggerSA One of two available source MAC addresses to filter on. Applicable only when captureTriggerEnable is set to true. The possible values are as in captureFilterSA. (default = 0)

userDefinedStat1DA One of two available destination MAC addresses to filter on. Applicable only when userDefinedStat1Enable is set to true. The possible values are as in capturefilteredA. (default = 0)

userDefinedStat1Enable true/false

Enables or disables the User Defined Statistics counter 1 that counts the number of frames filtered. (default = false)

Option Value Usage

anyAddr 0 (default) disables the destination address filter con-straint

addr1 1 sets the destination address filter constraint to trigger on frames with a destination MAC address that matches SA1and DA1mask as specified in the filter palette

notAddr1 2 sets the destination address filter constraint to trigger on all frames except those with a destination MAC address that matches SA1 andSA1 mask as speci-fied in the filter palette

addr2 3 sets the destination address filter constraint to trigger on frames with a destination MAC address that matches SA2 and SA2mask as specified in the filter palette

notAddr2 4 sets the destination address filter constraint to trigger on all frames except those with a destination MAC address that matches SA2 and SA2 mask as speci-fied in the filter palette


filterA

userDefinedStat1Error Applicable only when userDefinedStat1Enable is set to true. The possible values are as in capturefilterrror.

userDefinedStat1FrameSizeEnable true/false

Enables or disables the frame size constraint which specifies a range of frame sizes to count. (default = false)

userDefinedStat1FrameSizeFrom

Applicable only when userDefinedStat1FrameSizeEnable is enabled. The minimum range of the size of frame to be counted. (default = 64)

userDefinedStat1FrameSizeTo

Applicable only when userDefinedStat1FrameSizeEnable is enabled. The maximum range of the size of frame to be counted. (default = 1518)

userDefinedStat1Pattern

Applicable only when userDefinedStat1Enable is set to true. The possible values are as in captureFilterPattern. (default = 0)

userDefinedStat1SA One of two available source MAC addresses to filter on. Applicable only when userDefinedStat1Enable is set to true. The possible values are as in captureFilterSA. (default = 0)

userDefinedStat2DA One of two available destination MAC addresses to filter on. Applicable only when userDefinedStat2Enable is set to true. The possible values are as in capturefilteredA. (default = 0)

userDefinedStat2Enable true/false

Enables or disables User Defined Statistics counter 2 that counts the number of frames filtered. (default = false)

userDefinedStat2Error Applicable only when userDefinedStat2Enable is set to true. The possible values are as in capturefilterrror. (default = 0)

userDefinedStat2FrameSizeEnable true/false

Enables or disables the frame size constraint which specifies a range of frame sizes to count. (default = false)

userDefinedStat2FrameSizeFrom

Applicable only when userDefinedStat2FrameSizeEnable is enabled. The minimum range of the size of frame to be counted. (default = 64)

userDefinedStat2FrameSizeTo

Applicable only when userDefinedStat2FrameSizeEnable is enabled. The maximum range of the size of frame to be counted. (default = 1518)

userDefinedStat2Pattern

Applicable only when userDefinedStat2Enable is set to true. The possible values are as in captureFilterPattern. (default = 0)

userDefinedStat2SA One of two available source MAC addresses to filter on. Applicable only when userDefinedStat2Enable is set to true. The possible values are as in captureFilterSA. (default = 0)

COMMANDS

The filter command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

filter cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the filter command.


filter

filter config option valueModify the configuration options of the filter. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for filter.

filter get chasID cardID portIDGets the current configuration of the filter for port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling filter cget option value to get the value of the configuration option. Specific errors are:


filter set chasID cardID portIDSets the configuration of the filter in IxHAL for port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the filter config option value command. Specific errors are:


filter setDefault



# In this example we’ll generate a range of packets with different# frame sizes, DA/SA and data pattern in order to demonstrate# how a directly attached port can collect specific statistics and# trigger/filter on contents


# Assume card to be used is in slot 1set card 1set txPort 1set rxPort 2set portList [list [list $chas $card $txPort] \ [list $chas $card $rxPort] ]

port setFactoryDefaults $chas $card $txPortport setDefault

stream setDefaultstream config -numFrames 100000stream config -dma stopStreamstream config -frameSizeType sizeRandom

stream config -sa {00 00 00 01 01 01}stream config -saRepeatCounter contIncrementstream config -saMaskSelect {FF FF FF FC FC FC}stream config -da {00 00 00 01 01 02}stream config -daRepeatCounter contIncrementstream config -daMaskSelect {FF FF FF FC FC FC}


filterA

stream set $chas $card $txPort 1port set $chas $card $txPort

port setFactoryDefaults $chas $card $rxPortport setDefault

filter setDefaultfilter config -captureTriggerDA addr1filter config -captureTriggerSA addr1filter config -captureTriggerEnable true

filter config -captureFilterPattern pattern1filter config -captureFilterFrameSizeEnable truefilter config -captureFilterFrameSizeFrom 128filter config -captureFilterFrameSizeTo 1024filter config -captureFilterEnable true

filter config -userDefinedStat1Enable truefilter config -userDefinedStat2Enable truefilter config -userDefinedStat1DA addr1filter config -userDefinedStat2SA addr1

filter set $chas $card $rxPort

filterPallette setDefaultfilterPallette config -DA1 {00 00 00 01 01 02}filterPallette config -SA1 {00 00 00 01 01 01}filterPallette config -pattern1 {02 02}filterPallette config -patternMask1 {02 02}filterPallette set $chas $card $rxPortport set $chas $card $rxPort

ixWritePortsToHardware portListafter 1000

ixCheckLinkState portList

ixClearPortStats $chas $card $rxPortixStartPortCapture $chas $card $rxPortixStartPortTransmit $chas $card $txPortafter 1000ixCheckPortTransmitDone $chas $card $txPortixStopPortCapture $chas $card $rxPort

stat get allStats $chas $card $rxPort

set userStat1 [stat cget -userDefinedStat1]set userStat2 [stat cget -userDefinedStat2]set triggered [stat cget -captureTrigger]

capture get $chas $card $rxPortset captured [capture cget -nPackets]

ixPuts “$captured captured, $triggered triggered”ixPuts “stat1 = $userStat1, stat2 = $userStat2”

SEE ALSO filterPallette


filterPallette

NAME - filterPallettefilterPallette - configure the filter palettes of a port on a card on a chassis.

SYNOPSIS filterPallette sub-command options

DESCRIPTION The filterPallette command is used to configure the information that the receiv-ing frames are going to be filtered on. This palette applies to all the filters (cap-ture trigger, capture filter, user defined statistics 1 and 2) that are enabled by the filter command.

STANDARD OPTIONS

DA1 Only frames that contain this destination MAC address are filtered, captured or counted. (default = 00 00 00 00 00 00)

DA2 Only frames that contain this destination MAC address are filtered, captured or counted. (default = 00 00 00 00 00 00)

DAMask1 A bit mask that allows the user to specify which bits of the DA1 should be used when filtering. If the mask bit is set high, the pattern bit will be used in the filter. (default = 00 00 00 00 00 00)

DAMask2 A bit mask that allows the user to specify which bits of the DA2 should be used when filtering. If the mask bit is set high, the pattern bit will be used in the filter. (default = 00 00 00 00 00 00)

matchType1 Match type for pattern1 set in class member pattern1. The available match types are:

Option Value Usage

matchIpEthernetII 0 an Ethernet II packet.

matchIp8023Snap 1 an 802.3 SNAP packet.

matchVlan 2 a VLAN tagged packet.

matchUser 3 (default) a value as specified by pattern1, pattern Mask1 and patternOffset1.

matchIpPpp 4 a PPP format packet

matchIpCiscoHdlc 5 a Cisco HDLC format packet.

matchIpSAEthernetII 6 match the IP Source Address for an Ether-net II packet located at offset 26.

matchIpDAEthernetII 7 match the IP Destination Address for an Ethernet II packet located at offset 30.

matchIpSADAEthernetII 8 match the IP Source and Destination Address for an Ethernet II packet located at offset 26.

matchIpSA8023Snap 9 match the IP Source Address for an 802.3 Snap packet located at offset 34.

matchIpDA8023Snap 10 match the IP Destination Address for an 802.3 Snap packet located at offset 38.


filterPalletteA

matchType2 Match type for pattern2. The available match types are as in matchType1.

matchIpSADA8023Snap 11 match the IP Source and Destination Address for an 802.3 Snap packet located at offset 34.

matchIpSAPos 12 match the IP Source Address for an POS packet located at offset 16.

matchIpDAPos 13 match the IP Destination Address for an POS packet located at offset 20.

matchIpSADAPos 14 match the IP Source and Destination Addresses for an POS packet located at offset 16.

matchTcpSourcePortIPEthernetII 15 match the TCP Source Port for an Ethernet II packet located at offset 34.

matchTcpDestPortIPEthernetII 16 match the TCP Destination Port for an Ethernet II packet located at offset 36.

matchUdpSourcePortIPEthernetII 17 match the UDP Source Port for an Ether-net II packet located at offset 34.

matchIpSAPos 12 match the IP Source Address for an POS packet located at offset 16.

matchIpDAPos 13 match the IP Destination Address for an POS packet located at offset 20.

matchIpSADAPos 14 match the IP Source and Destination Addresses for an POS packet located at offset 16.

matchTcpSourcePortIPEthernetII 15 match the TCP Source Port for an Ethernet II packet located at offset 34.

matchTcpDestPortIPEthernetII 16 match the TCP Destination Port for an Ethernet II packet located at offset 36.

matchUdpSourcePortIPEthernetII 17 match the UDP Source Port for an Ether-net II packet located at offset 34.

matchUdpDestPortIPEthernetII 18 match the UDP Destination Port for an Ethernet II packet located at offset 36.

matchTcpSourcePortIP8023Snap 19 match the TCP Source Port for an 802.3 Snap packet located at offset 42.

matchTcpDestPortIP8023Snap 20 match the TCP Destination Port for an 802.3 Snap packet located at offset 44.

matchUdpSourcePortIP8023Snap 21 match the UDP Source Port for an 802.3 Snap packet located at offset 42.

matchUdpDestPortIP8023Snap (22) match the UDP Destination Port for an 802.3 Snap packet located at offset 44

matchTcpSourcePortIPPos 23 match the TCP Source Port for a POS packet located at offset 24.

matchTcpDestPortIPPos 24 match the TCP Destination Port for a POS packet located at offset 26.

matchUdpSourcePortIPPos 25 match the UDP Source Port for a POS packet located at offset 24.

matchUdpDestPortIPPos 26 match the UDP Source Port for a POS packet located at offset 26

Option Value Usage


filterPallette

pattern1 Only frames that contain this pattern at offset patternOffset1 are filtered, captured or counted. (default = 00)

pattern2 Only frames that contain this pattern at offset patternOffset2 are filtered, captured or counted. (default = 00)

patternMask1 A bit mask that allows the user to specify which bits of pattern1 should be used when filtering. If the mask bit is set high, the pattern bit will be used in the filter. (default = 00)

patternMask2 A bit mask that allows the user to specify which bits of pattern2 should be used when filtering. If the mask bit is set high, the pattern bit will be used in the filter. (default = 00)

patternOffset1 Offset of pattern1 in the frame to be filtered, captured or counted. (default = 12)

patternOffset2 Offset of pattern2 in the frame to be filtered, captured or counted. (default = 12)

SA1 Only frames that contain this source MAC address are filtered, captured or counted. (default = 00 00 00 00 00 00)

SA2 Only frames that contain this source MAC address are filtered, captured or counted. (default = 00 00 00 00 00 00)

SAMask1 A bit mask that allows the user to specify which bits of the SA1 should be used when filtering. If the mask bit is set high, the pattern bit will be used in the filter. (default = 00 00 00 00 00 00)

SAMask2 A bit mask that allows the user to specify which bits of the SA2 should be used when filtering. If the mask bit is set high, the pattern bit will be used in the filter. (default = 00 00 00 00 00 00)

DEPRECATEDSTANDARD OPTIONS

type1

type2

typeMask1

typeMask2

COMMANDS The filterPallette command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

filterPallette cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the filterPallette command.


filterPalletteA

filterPallette config option valueModify the configuration options of the filterPallette. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for filterPallette.

filterPallette get chasID cardID portIDGets the current config of the filterPallette on port portID on card cardID, chassis chasID. from its hardware. Call this command before calling filterPallette cget option value to get the value of the configuration option. Specific errors are:


filterPallette set chasID cardID portID

Sets the configuration of the filterPallette in IxHAL on port with id portID on card cardID, chassis chasID by reading the configuration option values set by the filterPallette config option value command. Specific errors are:


filterPallette setDefault


filterPallette write chasID cardID portIDWrites or commits the changes in IxHAL to hardware for the filter palette on port with id portID on card cardID, chassis chasID. Before using this command, use the filterPallette set command to configure the filterPallette related parameters in IxHAL. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• Network problem between the client and chassis

EXAMPLES See examples under filter.

SEE ALSO filter


forcedCollisions

NAME - forcedCollisionsforcedCollisions - configure the forced collision parameters for 10/100 ports

SYNOPSIS forcedCollisions sub-command options

DESCRIPTION The forcedCollisions command is used to configure the forced collision parame-ters.

STANDARD OPTIONS

collisionDuration The duration of each collision, measured in nibbles. (default = 10)

consecutiveCollisions The number of consecutive collisions to generate at a time. Collisions take place on the first received packet after enabled. (default = 4)

consecutiveNon-CollidingPackets

After each time that the number of programmed consecutive collisions have occurred this is the number of packets that will not be modified. (default = 4)

continuoustrue / false

If true, the pattern of collisions and non-collisions is repeated indefinitely. (default = true)

enable true / false Enables the generation of forced collisions. (default = false)

packetOffset The offset from the beginning of packet active carrier sense (the beginning of the preamble) to the start of the collision, measured in nibbles. (default = 64)

repeatCount If continuous operation is not selected, this value is the number of times that the pattern of collisions/non-collisions is repeated. (default = 2)

COMMANDS The forcedCollisions command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

forcedCollisions cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the forcedCollisions command.

forcedCollisions config option valueModify the configuration options of the forcedCollisions. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for forcedCollisions.

forcedCollisions get chasID cardID portIDGets the current configuration of the forcedCollisions header for port with id portID on card cardID, chassis chasID from its hardware. Call this command before calling forcedCollisions cget option value to get the value of the configu-ration option. Specific errors are:



forcedCollisionsA

• The port does not support forced collisions

forcedCollisions set chasID cardID portIDSets the forcedCollisions configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the forcedColli-sions config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is owned by another user• Configured parameters are not valid for this setting• The port does not support forced collisions

forcedCollisions setDefault


EXAMPLES package require IxTclHalset host galaxyixInitialize $hostset chas [ixGetChassisID $host]

# Assume that card 1 is a 10/100 cardset card 1set portA 1set portB 2

# Set up mappingmap new -type one2onemap config -type one2onemap add $chas $card $portA $chas $card $portBmap add $chas $card $portB $chas $card $portAset portList [list [list $chas $card $portA] \ [list $chas $card $portB]]

# Set up both ports to 10Mbps and half duplexport setDefault port config -autonegotiate falseport config -duplex halfport config -speed 10port set $chas $card $portAport set $chas $card $portB

# Configure forced collisionsforcedCollisions setDefaultforcedCollisions config -enable 1forcedCollisions config -consecutiveNonCollidingPackets 9forcedCollisions set $chas $card $portA forcedCollisions set $chas $card $portB

# Make the collision backoff algorithm try hardercollisionBackoff setDefaultcollisionBackoff config -maxRetryCount 32collisionBackoff set $chas $card $portAcollisionBackoff set $chas $card $portB

# Configure the streams to transmit at 50%stream setDefaultstream config -percentPacketRate 50stream config -rateMode usePercentRate


forcedCollisions

stream config -dma stopStreamstream config -numFrames 10000stream set $chas $card $portA 1stream set $chas $card $portB 1

# Write config to hardware, check the link state and clear statistics# Error checking omitted for brevityixWritePortsToHardware one2oneArrayafter 1000ixCheckLinkState one2oneArrayixClearStats one2oneArray

# Start collisionsixStartCollisions one2oneArray# Make sure that ports don’t attempt to transmit at the same instantixStartStaggeredTransmit one2oneArray

ixCheckTransmitDone one2oneArray

ixCollectStats $portList collisions rxStats totals

ixPuts “$totals total collisions, port 1 = $rxStats(1,1,1), port 2 = $rxStats(1,1,2)”

SEE ALSO portGroup


frameRelayA

NAME - frameRelayframeRelay - configure the Frame Relay header for a Packet over Sonet frame

SYNOPSIS frameRelay sub-command options

DESCRIPTION The frameRelay command is used to configure the Frame Relay parameters.Note: To configure the frameRelay parameters, sonet config -header needs to be configured for the right Frame Relay headers first.

STANDARD OPTIONS

addressSize Address length in the Frame Relay frame header. (default = 2)

becn Backward congestion notification bit in the Frame Relay address field. ( default = 0)

commandResponse Command or Response bit in the Frame Relay address field. (default = 0)

control Control information. (default = 3)

discardEligibleBit Discard eligible bit in the Frame Relay address field. (default = 0)

dlci DLCI core indicator bit in the Frame Relay address field. (default = 0)

dlciCore Frame Relay address field. (default = 0)

etherType Ethertype of protocol in use. (default = 65535)

extentionAddress0 Extention address 0 bit in theFrame Relay address field. (default = 0)




fecn Forward congestion notification bit in the Frame Relay address field.( default = 0)

nlpid Network layer protocol identifier to identify the type of upper-layer protocol transmitted in the frame. (default = 255)

COMMANDS The frameRelay command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

frameRelay cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the frameRelay command.


frameRelay

frameRelay config option valueModify the configuration options of the frameRelay. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for frameRelay.

frameRelay decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• The captured frame is not a valid Frame Relay frame

frameRelay get chasID cardID portIDGets the current configuration of the frameRelay header for port with id portID on card cardID, chassis chasID from its hardware. Call this command before calling frameRelay cget option value to get the value of the configuration option. Specific errors are:

• No connection to a chassis• Invalid port number• The port is not a Packet over Sonet port

frameRelay set chasID cardID portIDSets the frameRelay configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the frameRelay config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• The port is not a Packet over Sonet port.

frameRelay setDefault



# Connect to chassis and get chassis IDset host localhostixInitialize $hostset chas [ixGetChassisID $host]

# Assuming that an OC48 POS card is in slot 8set card 8set port 1set portList [list [list $chas $card $port]]

# Get the type of card and check if it’s the correct typeset ifType [card getInterface $chas $card]if {$ifType != $::interfaceOc48} { ixPuts “Card $card is not an OC48c POS card ($ifType)”} else {

# Need to set header type to Frame Relay


frameRelayA

sonet setDefault sonet config -interfaceType oc48 sonet config -header sonetFrameRelay2427 sonet set $chas $card 1

stream setDefault

# Set DLCI and BECN bit frameRelay setDefault frameRelay config -dlci 22 frameRelay config -becn 1 frameRelay set $chas $card $port

stream set $chas $card $port 1

ixWriteConfigToHardware portList}

SEE ALSO


hdlc

NAME - hdlchdlc - configure the HDLC header for a Packet over Sonet frame

SYNOPSIS hdlc sub-command options

DESCRIPTION The hdlc command is used to configure the HDLC parameters.

STANDARD OPTIONS

address The one-byte address field of the HDLC header used in conjunction with Packet over Sonet. Defined values include:

control The one-byte control field of the HDLC header used in conjunction with Packet over Sonet. Defined values include:

protocol The two-byte protocol field of the HDLC header used in conjunction with Packet over Sonet. Defined values include:

Option Value Usage

pppAddress 0xff (default)

ciscoAddress 0x0f

Option Value Usage

pppControl 0x03 (default)

ciscoControl 0x00

Option Value Usage

pppIp 0x0021 (default)

ciscoIp 0x0800

ciscoIpV6 0x86dd

pppPaddingProtocol 0x0001

pppOSI 0x0023

pppXeroxIDP 0x0025

pppDECnet 0x0027

pppAppletalk 0x0029

pppIPX 0x002b

pppCompressedTCPIP 0x002d

pppUncompressedTCPIP 0x002f

pppBPDU 0x0031

pppSTII 0x0033

pppBanyanVines 0x0035

pppAppleTalkEDDP 0x0039

pppAppleTalkSmartBuffered 0x003b

pppMultiLink 0x003d

pppFirstChoiceCompression 0x00fd


hdlcA

COMMANDS The hdlc command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

hdlc cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the hdlc command.

hdlc config option valueModify the configuration options of the hdlc. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for hdlc.

hdlc decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and makes the data available in the STANDARD OPTIONS through hdlc cget. The capFrame parameter must be obtained through a call to stream packetview. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid Hdlc frame• The port is not a Packet over Sonet port.

hdlc get chasID cardID portIDGets the current configuration of the hdlc header for port with id portID on card cardID, chassis chasID from its hardware. Call this command before calling hdlc cget option value to get the value of the configuration option. Specific errors are:

• No connection to a chassis• Invalid port number• The port is not a Packet over Sonet port.

pppHelloPackets 0x0201

pppIBMSourceRoutingBPDU 0x0203

pppLuxcom 0x0231

pppSigmaNetworkSystems 0x0233

pppIPControlProtocol 0x8021

pppOSIControlProtocol 0x8023

pppXeroxIDPControlProtocol 0x8025

pppDECnetControlProtocol 0x8027

pppAppletalkControlProtocol 0x8029

pppIPXControlProtocol 0x802b

pppBridgingNCP 0x8031

pppMultiLinkControlProtocol 0x803d

pppComprControlProtocol 0x80fd

pppLinkControlProtocol 0xc021

pppPasswordAuthProtocol 0xc023

pppLinkQualityReport 0xc025

Option Value Usage


hdlc

hdlc set chasID cardID portIDSets the hdlc configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the hdlc config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The configured parameters are not valid for this port• The port is not a Packet over Sonet port.

hdlc setCisco protocolType chasID cardID portIDSets the configuration of the hdlc header to ciscoAddress and ciscoControl in IxHAL for port with id portID on card cardID, chassis chasID. Specific errors are:

• No connection to a chassis• Invalid port number• The configured parameters are not valid for this port• The port is not a Packet over Sonet port.• The protocolType is not one of ciscoIp or ciscoIpV6.

hdlc setDefault


hdlc setPpp protocolType chasID cardID portIDSets the configuration of the hdlc header to pppAddress and pppControl in IxHAL for port with id portID on card cardID, chassis chasID. Specific errors are:

• No connection to a chassis• Invalid port number• The configured parameters are not valid for this port• The port is not a Packet over Sonet port.• The protocolType is not pppIp.


set addressByte($::pppAddress) “pppAddress”set addressByte($::ciscoAddress) “ciscoAddress”

set controlByte($::pppControl) “pppControl”set controlByte($::ciscoControl) “ciscoControl”

set protocolByte($::pppIp) “pppIp”set protocolByte($::ciscoIp) “cisco”set protocolByte($::pppPaddingProtocol) “pppPaddingProtocol”set protocolByte($::pppOSI) “pppOSI”set protocolByte($::pppXeroxIDP) “pppXeroxIDP”set protocolByte($::pppDECnet) “pppDECnet”set protocolByte($::pppAppletalk) “pppAppletalk”set protocolByte($::pppIPX) “pppIPX”set protocolByte($::pppCompressedTCPIP) “pppCompressedTCPIP”set protocolByte($::pppUncompressedTCPIP) “pppUncompressedTCPIP”set protocolByte($::pppBPDU) “pppBPDU”set protocolByte($::pppSTII) “pppSTII”


hdlcA

set protocolByte($::pppBanyanVines) “pppBanyanVines”set protocolByte($::pppAppleTalkEDDP) “pppAppletalkEDDP”set protocolByte($::pppMultiLink) “pppMultiLink”set protocolByte($::pppFirstChoiceCompression) “pppFirstChoiceCompression”set protocolByte($::pppHelloPackets) “pppHelloPackets”set protocolByte($::pppIBMSourceRoutingBPDU) “pppIBMSourceRoutingBPDU”set protocolByte($::pppLuxcom) “pppLuxcom”set protocolByte($::pppSigmaNetworkSystems) “pppSigmaNetworkSystems”set protocolByte($::pppIPControlProtocol) “pppIPControlProtocol”set protocolByte($::pppOSIControlProtocol) “pppOSIControlProtocol”set protocolByte($::pppXeroxIDPControlProtocol) “pppXeroxIDPControlProtocol”set protocolByte($::pppDECnetControlProtocol) “pppDECnetControlProtocol”set protocolByte($::pppAppletalkControlProtocol) “pppAppletalkControlProtocol”set protocolByte($::pppIPXControlProtocol) “pppIPXControlProtocol”set protocolByte($::pppBridgingNCP) “pppBridgingNCP”set protocolByte($::pppMultiLinkControlProtocol) “pppMultiLinkControlProtocol”set protocolByte($::pppComprControlProtocol) “pppComprControlProtocol”set protocolByte($::pppLinkControlProtocol) “pppLinkControlProtocol”set protocolByte($::pppPasswordAuthProtocol) “pppPasswordAuthProtocol”set protocolByte($::pppLinkQualityReport) “pppPasswordAuthProtocol”

proc printOptions {} \{ set addr [hdlc cget -address] set cntrl [hdlc cget -control] set protocol [hdlc cget -protocol]# ixPuts “address $addressByte($addr), control $controlByte($cntrl), \# protocol $protocolByte($protocol)” ixPuts “address $addr, control $cntrl, protocol $protocol”}


# Assuming that a POS card is in slot 3set card 3

set portList [list [list $chas $card 1] [list $chas $card 2]]

# Check for missing cardif {[card get $chas $card] != 0} \{ ixPuts “Card $card does not exist” break}


hdlc

# Get the type of card and check if it’s the correct typeset cardType [card cget -type]if {$cardType != $::cardPOS2Port} \{ ixPuts “Card $card is not an 2 port POS card” exit}

# Set the options to default valueshdlc setDefault ixWriteConfigToHardware portList

# Get the current hdlc state from the cardshdlc get $chas $card 1printOptions

# Set to Cisco valueshdlc setCisco ciscoIp $chas $card 1ixWritePortsToHardware portListset x [hdlc cget -address]if {“0x$x” == $::ciscoAddress} { ixPuts “OK”} else { ixPuts “NG”}ixStartPortCapture $chas $card 1ixStartPortTransmit $chas $card 2after 2000capture get $chas $card 1 captureBuffer get $chas $card 1 1 1captureBuffer getframe 1set frameData [captureBuffer cget -frame]

# Now have hdlc decode the headerhdlc decode $frameData $chas $card 1printOptions

SEE ALSO ppp


icmpA

NAME - icmpicmp - configure the ICMP parameters for a port on a card on a chassis

SYNOPSIS icmp sub-command options

DESCRIPTION The icmp command is used to configure the ICMP-specific information used when building ICMP-type packets.

STANDARD OPTIONS

checksum Read-only Value of the checksum in the valid icmp stream. Valid only if the stream set is performed.

code Code for each type of message. (default = 0)

id ID for each ping command. (ID for the echoRequest)

sequence Sequence number for each ping command (sequence number for the echoRequest) (default = 0)

type Read-only The type of ICMP message to be sent. Options are:

Usage Value Usage

echoReply 0 when echo message is received (when IP address is valid and receiving side supports the requested func-tions)

destUnreachable 3 when a datagram cannot reach its destination

sourceQuench 4 when gateway does not have the buffer space needed to queue the datagrams

redirect 5 when the gateway and the host identified by the inter-net source address of the datagram are on the same network

echoRequest 8 when network connection is to be tested (via ping command test the validity of IP address)

timeExceeded 11 when time to live field is 0

parameterProblem 12 when there is a problem with the header parameters

timeStampRequest 13 to request the timestamp of the receipt at the other end

timeStampReply 14 to get the timestamp when the datagram began its return

infoRequest 15 when host needs to find out the number of the net-work it is on.

infoReply 16 when infoRequest is received

maskRequest 17 to get the subnet address mask from the router

maskReply 18 when maskRequest is received


icmp

COMMANDS The icmp command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

icmp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the icmp command.

icmp config option valueModify the ICMP configuration options of the port. If no option is specified, returns a list describing all of the available ICMP options (see STANDARD OPTIONS) for port.

icmp decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. icmp cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid Icmp frame

icmp get chasID cardID portIDGets the current ICMP configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling icmp cget option value to get the value of the configuration option. Specific errors are:


icmp set chasID cardID portIDSets the ICMP configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the icmp config option value command. Specific errors are:


icmp setDefault



# In this example we’ll send an echo response message from a port# back to itself and decode the received packet


# Assume card to be used is in slot 1


icmpA

set card 1set port 1set portList [list [list $chas $card $port]]

# Some defines for IP setupset portMAC {00 00 00 01 01 01}set portIP {192.168.18.1}set portMask {255.255.255.0}

set destMAC {00 00 00 01 01 02}set destIP {192.168.18.2}set destMask {255.255.255.0}

# Put the port in loopback modeport setFactoryDefaults $chas $card $portport setDefaultport config -loopback true

# Stream: 1 packet at 1%stream setDefaultstream config -numFrames 1stream config -dma stopStreamstream config -rateMode usePercentRatestream config -percentPacketRate 1

# set protocol to IPprotocol setDefaultprotocol config -name ipprotocol config -ethernetType ethernetII

# Set up IP: icmp with 46 byte packetip setDefaultip config -ipProtocol icmpip config -totalLength 46ip config -sourceIpAddr $portIPip config -sourceIpMask $portMaskip config -sourceClass classCip config -destIpAddr $destIPip config -destIpMask $destMaskip config -destClass classCip set $chas $card $port

# Send an echo reply with some data in id and sequenceicmp setDefaulticmp config -type echoReplyicmp config -code 0icmp config -id 3icmp config -sequence 42icmp set $chas $card $port


# Set up the portixWritePortsToHardware portList

# Start capture and send the packetafter 1000ixStartPortCapture $chas $card $portixStartPortTransmit $chas $card $port

# Stop port capture


icmp

after 1000ixStopPortCapture $chas $card $port

# Get the capture buffercaptureBuffer get $chas $card $portif {[captureBuffer cget -numFrames] == 0} \{ ixPuts “No packets received”} \else \{ # Get the frame captureBuffer getframe 1 set data [captureBuffer cget -frame]

# And decode the data icmp decode $data $chas $card $port ixPuts -nonewline “Received packet: code = “ ixPuts -nonewline [icmp cget -code] ixPuts -nonewline “, id = “ ixPuts -nonewline [icmp cget -id] ixPuts -nonewline “, sequence = “ ixPuts [icmp cget -sequence]}

SEE ALSO stream, ip, udp


igmpA

NAME - igmpigmp - configure the IGMP parameters for a port on a card on a chassis

SYNOPSIS igmp sub-command options

DESCRIPTION The igmp command is used to configure the IGMP-specific information used when building IGMP-type packets.

STANDARD OPTIONS

groupIpAddress IP Multicast group address of the group being joined or left. (default = 224.0.1.14)

maxResponseTime The maximum allowed time before sending a responding report in units of 1/10 second. (default = 100)

mode Describes how to vary the groupIpAddress when repeatCount is greater than 1. The options are:

repeatCount Number of times of IGMP messages to be sent. (default = 0)

type The type of IGMP message to be sent (default = membershipReport2). Options are:

version The version number of IGMP (default = igmpVersion2). Options are:

Option Value Usage

igmpIdle 0 (default)

igmpIncrement 1

igmpDecrement 2

igmpContIncrement 3

igmpContDecrement 4

Option Value Usage

membershipQuery 17 General or group specific query messages sent by the DUT

membershipReport1 18 An IGMP version 1 message sent by client to inform the DUT of its interest to join a group

dvmrpMessage 19 Distance-Vector Multicast Routing Protocol message

membershipReport2 22 An IGMP version 2 message sent by client to inform the DUT of its interest to join a group

leaveGroup 23 An IGMP version21message sent by client to inform the DUT of its interest to leave a group

Option Value Usage

igmpVersion1 1 version 1

igmpVersion2 2 version 2


igmp

COMMANDS The igmp command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

igmp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the igmp command.

igmp config option valueModify the IGMP configuration options of the port. If no option is specified, returns a list describing all of the available IGMP options (see STANDARD OPTIONS) for port.

igmp decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. igmp cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid Igmp frame

igmp get chasID cardID portIDGets the current IGMP configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling igmp cget option value to get the value of the configuration option. Specific errors are:


igmp set chasID cardID portIDSets the IGMP configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the igmp config option value command. Specific errors are:


igmp setDefault




set card 1set port 1

set portList [list [list $chas $card $port]]


igmpA

set portMAC {00 00 00 01 01 01}set portIP {192.168.18.1}set portMask {255.255.255.0}


port setFactoryDefaults $chas $card $portport setDefault

# Stream: 256 packetsstream setDefaultstream config -numFrames 256stream config -sa $portMACstream config -da $destMACstream config -dma stopStream

# Set up IPip setDefaultip config -ipProtocol igmpip config -sourceIpAddr $portIPip config -sourceIpMask $portMaskip config -sourceClass classCip config -destIpAddr $destIPip config -destIpMask $destMaskip config -destClass classCip set $chas $card $port

protocol setDefaultprotocol config -name ipV4protocol config -ethernetType ethernetII

igmp setDefaultigmp config -groupIpAddress {224.0.0.1}igmp config -type membershipQueryigmp set $chas $card $port



SEE ALSO stream, ip, udp


igmpAddressTable

NAME - igmpAddressTableigmpAddressTable - configure the IGMP address table parameters for a port on a card on a chassis

SYNOPSIS igmpAddressTable sub-command options

DESCRIPTION The igmpAddressTable command is used to configure the IGMP address table-specific information used when building IGMP address table. Entries may be added or deleted; editing of entries is accomplished by deleting the old entry and adding a new one.

STANDARD OPTIONS

none

COMMANDS The igmpAddressTable command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

igmpAddressTable addItem

Creates IGMP and MAC address ranges. Specific errors are:• The configured parameters are not valid for this port

igmpAddressTable cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the igmpAddressTable command.

igmpAddressTable clear

Clears the IGMP address table.

igmpAddressTable config option valueModify the IGMP address table configuration options of the port. If no option is specified, returns a list describing all of the available igmpAddressTable options (see STANDARD OPTIONS) for port.

igmpAddressTable delItem

Deletes IGMP and MAC address ranges.

igmpAddressTable get chasID cardID portIDGets the current IGMP address table configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling igmpAd-dressTable cget option value to get the value of the configuration option.

igmpAddressTable getFirstItem

Gets the first IGMP and MAC address range out of the IGMP address table.


igmpAddressTableA

igmpAddressTable getNextItem

Gets the next IGMP and MAC address range out of the IGMP address table.

igmpAddressTable set chasID cardID portIDSets the IGMP address table configuration of the port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the igm-pAddressTable config option value command.

igmpAddressTable setDefault


EXAMPLES See examples under igmpServer.

SEE ALSO igmp



NAME - igmpAddressTableItemigmpAddressTableItem - configure the IGMP address table parameters for a port on a card on a chassis

SYNOPSIS igmpAddressTableItem sub-command options

DESCRIPTION The igmpAddressTableItem command is used to configure the IGMP address table-specific information used when building IGMP address table.

STANDARD OPTIONS

fromClientAddress The first client address for the client address range. (default = 0.0.0.0)

fromGroupAddress The first group address for the group address range. (default = 0.0.0.0)

numClientAddresses Number of client consecutive addresses. (default = 1)

numGroupAddresses Number of group consecutive addresses. (default = 1)

toClientAddress Read-Only. The last client address for the client address range. (default = 0.0.0.0)

toGroupAddress Read-Only. The last group address for the group address range. (default = 0.0.0.0)

COMMANDS The igmpAddressTableItem command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

igmpAddressTableItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the igmpAddressTableItem command.

igmpAddressTableItem config option valueModify the IGMP address table configuration options of the port. If no option is specified, returns a list describing all of the available igmpAddressTableItem options (see STANDARD OPTIONS) for port.

igmpAddressTableItem get

Gets the current IGMP address table item configuration. Call this command before calling igmpAddressTableItem cget option value to get the value of the configuration option.

igmpAddressTableItem set Sets the IGMP address table item configuration, by reading the configuration option values set by the igmpAddressTableItem config option value command.


igmpAddressTableItemA

igmpAddressTableItem setDefault


EXAMPLES See examples under igmpServer.

SEE ALSO igmpAddressTable


igmpServer

NAME - igmpServerigmpServer - configure the IGMP server parameters.

SYNOPSIS igmpServer sub-command options

DESCRIPTION The igmpServer command is used to configure the IGMP server parameters.

STANDARD OPTIONS

enableQueryResponse Enables responses after initial join is sent. (default = true)

rate The rate at which reports are sent, expressed in frames per second.

repeatCount Number of IGMP reports to be sent. Not implemented yet. (default = 3)

reportFrequency Report frequency in seconds. (default = 120)

reportMode Options are:

sendRouterAlert Enable sending router alert. (default = faulse)

version The version number of IGMP. Options are:

COMMANDS The igmpServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

igmpServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the igmpServer command.

igmpServer config option valueModify the IGMP server configuration options of the port. If no option is speci-fied, returns a list describing all of the available igmpServer options (see STAN-DARD OPTIONS) for port.

Option Value Usage

igmpReportToOneWhenQueried 0)

igmpReportToAllWhenQueried 1)

igmpReportToAllUnsolicited 2 (default = 2)

Option Value Usage

igmpVersion1 1

igmpVersion2 2 default


igmpServerA

igmpServer get

Gets the current IGMP server configuration. Call this command before calling igmpServer cget option value to get the value of the configuration option. Spe-cific errors are:


igmpServer set Sets the IGMP server configuration, by reading the configuration option values set by the igmpServer config option value command. Specific errors are:


igmpServer setDefault



ixInitialize ruby

set chassis [chassis cget -id]set card 4set port 1set portList [list [list $chassis $card $port]]

port setFactoryDefaults $chassis $card $port

# Set up IP address table so we can respond to ARPsipAddressTable setDefault ipAddressTable config -defaultGateway {1.1.1.1}ipAddressTableItem setDefault ipAddressTableItem config -fromIpAddress {2.2.2.2}ipAddressTableItem config -fromMacAddress {00 DE BB 00 00 01}ipAddressTableItem config -numAddresses 1ipAddressTableItem set ipAddressTable addItem ipAddressTable set $chassis $card $port

# Set up IGMP server to send reportsigmpServer setDefault igmpServer config -reportMode 1igmpServer config -reportFrequency 100igmpServer config -repeatCount 10igmpServer set $chassis $card $port

# Set up IGMP table for group addressesigmpAddressTable clear igmpAddressTableItem setDefault igmpAddressTableItem config -fromGroupAddress {224.0.1.1}igmpAddressTableItem config -fromClientAddress {2.2.2.2}igmpAddressTableItem config -numGroupAddresses 10igmpAddressTableItem config -numClientAddresses 1igmpAddressTableItem set igmpAddressTable addItem


igmpServer

igmpAddressTable set $chassis $card $port

# Start the protocol server for Arp and IGMPprotocolServer setDefault protocolServer config -enableArpResponse trueprotocolServer config -enableIgmpQueryResponse trueprotocolServer set $chassis $card $port

# Tell the hardware about itixWritePortsToHardware portList

SEE ALSO igmpAddressTable


ipA

NAME - ipip - configure the IP parameters for a port on a card on a chassis

SYNOPSIS ip sub-command options

DESCRIPTION The ip command is used to configure the IP-specific information used when building IP-type packets if the protocol config –name has been set to ip. See RFC 791 for a complete definition of IP header fields.

STANDARD OPTIONS

checksum Read-only. Value of the checksum in the valid ip stream. Valid only if the stream set is performed.

cost Part of the Type of Service byte of the IP header datagram (bit 6). Options include:

delay Part of the Type of Service byte of the IP header datagram (bit 3). Options include:

destClass Class type associated with the destination IP address of the Ixia port. Options include:

destDutIpAddr IP address of the DUT (device under test) port. This value is stored at the TclHal level. (default = 127.0.0.1)

destIpAddr Destination IP address of the Ixia port. (default = 127.0.0.1)

Option Value Usage

normalCost 0 (default)

lowCost 1

Option Value Usage

NormalDelay 0 (default)

LowDelay 1

Option Value Usage

classA 0

classB 1

classC 2 (default)

classD 3

noClass 4


ip

destIpAddrMode Specifies how the destination IP address will be incremented or decremented. If destIpAddrRepeatCount is set to 1, this variable has no effect. Possible values include:

destIpAddrRepeat-Count

Number of destination IP addresses. If set to 1, destIpAddrMode has no effect (default = 1)

destIpMask Destination IP subnet mask. (default = 255.0.0.0)

destMacAddr Destination MAC address, generally the MAC address of the DUT port; this field will be modified on receipt of ARP frames. This value is stored at the TclHal level. (default = 00 00 00 00 00 00)

fragment If set to true, this field indicates this is a fragmented datagram. Used in conjuction with identifier, fragmentoffset and lastFragment. Options include:

fragmentOffset This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero (default = 0)

identifier An identifying value assigned by the sender to aid in assembling the fragments of a datagram. (default = 0)

Option Value Usage

ipIdle 0 (default) no change to IP address regardless of des-tIpAddrRepeatCount

ipIncrHost 1 increment the network portion of the IP address for as many destIpAddrRepeatCount specified

ipDecrHost 2 decrement the host portion of the IP address for as many destIpAddrRepeatCount specified

ipContIncrHost 3 Continuously increment the host portion of the IP address for each packet

ipContDecrHost 4 Continuously decrement the host portion of the IP address for each packet

ipIncrNetwork 5 increment the network portion of the IP address for as many destIpAddrRepeatCount specified

ipDecrNetwork 6 increment the host portion of the IP address for as many destIpAddrRepeatCount specified

ipContIncrNetwork 7 Continuously increment the network portion of the IP address for each packet

ipContDecrNetwork 8 Continuously decrement the host portion of the IP address for each packet.

ipRandom 9 Generate random IP addresses

Option Value Usage

may 0 (default)

dont 1


ipA

ipProtocol The next level protocol used in the data portion of the internet datagram. Possible values include:

Option Value Usage

reserved 0

ipV6HopToHop 0

icmp 1

igmp 2

ggp 3

ip 4

st 5

tcp 6

ucl 7

egp 8

igp 9

bbn_rcc_mon 10

nvp_ii 11

pup 12

argus 13

emcon 14

xnet 15

chaos 16

udp 17 (default)

mux 18

dcn_meas 19

hmp 20

prm 21

xns_idp 22

trunk_1 23

trunk_2 24

leaf_1 25

leaf_2 26

rdp 27

irtp 28

iso_tp4 29

netblt 30

mfe_nsp 31

merit_inp 32

sep 33

cftp 62

sat_expak 64

mit_subnet 65

rvd 66

ippc 67

sat_mon 69


ip

lastFragment Controls whether there are additional fragments used to assemble this datagram. Options include:

lengthOverride true / false

Allows to change the length in ip header. (default = false)

options Variable length option field in the IP header datagram. (default = { })

precedence Part of the Type of Service byte of the IP header datagram. Establishes precedence of delivery. Possible values are:

reliability Part of the Type of Service byte of the IP header datagram (bit 5). Options include:

reserved Part of the Type of Service byte of the IP header datagram (bit 7 - 0/1). (default = 0)

sourceClass Class type associated with the source IP address. Options include:

ipcv 71

br_sat_mon 76

wb_mon 78

wb_expak 79

Option Value Usage

Option Value Usage

last 0 (default)

more 1

Option Value Usage

routine 0x0 (default)

priority 0x1

immediate 0x2

flash 0x3

flashOverride 0x4

criticEcp 0x5

internetControl 0x6

networkControl 0x7

Option Value Usage

normalReliability 0 (default)

highReliability 1

Option Value Usage

classA 0

classB 1

classC 2 (default)

classD 3

noClass 4


ipA

sourceIpAddr Source IP address. (default = 127.0.0.1)

sourceIpAddrMode Specifies how the source IP address will be incremented or decremented. If sourceIpAddrRepeatCount is set to 1, this variable has no effect. Possible values include:

sourceIpAddrRepeatCount

Number of source IP addresses. If set to 1, sourceAddrMode has no effect. (default = 1)

sourceIpMask Source IP subnet mask. (default = 255.0.0.0)

throughput Part of the Type of Service byte of the IP header datagram (bit 4). Options include:

totalLength Total Length is the length of the datagram, measured in octets, including internet header and data. (default = 46)

ttl Time-to-Live, measured in units of seconds. (default = 64)

useValidChecksum true/false

If set to true, a valid IP checksum will be calculated for each frame. If set to false, the IP checksum will be invalid. (default = true)

COMMANDS The ip command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

Option Value Usage

ipIdle 0 (default) no change to IP address regardless of sour-ceIpAddrRepeatCount

ipIncrHost 1 increment the network portion of the IP address for as many sourceIpAddrRepeatCount specified

ipDecrHost 2 decrement the host portion of the IP address for as many sourceIpAddrRepeatCount specified

ipContIncrHost 3 Continuously increment the host portion of the IP address for each packet

ipContDecrHost 4 Continuously decrement the host portion of the IP address for each packet

ipIncrNetwork 5 increment the network portion of the IP address for as many sourceIpAddrRepeatCount specified

ipDecrNetwork 6 increment the host portion of the IP address for as many sourceIpAddrRepeatCount specified

ipContIncrNetwork 7 Continuously increment the network portion of the IP address for each packet

ipContDecrNetwork 8 Continuously decrement the host portion of the IP address for each packet.

ipRandom 9 Generate random IP addresses

Option Value Usage

normalThruput 0 (default)

highThruput 1


ip

ip cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ip command.

ip config option valueModify the IP configuration options of the port. If no option is specified, returns a list describing all of the available IP options (see STANDARD OPTIONS) for port.

ip decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. ip cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid IP frame

ip get chasID cardID portIDGets the current IP configuration of the port with id portID on card cardID, chas-sis chasID. Call this command before calling ip cget option value to get the value of the configuration option. Specific errors are:


ip set chasID cardID portIDSets the IP configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the ip config option value command. Specific errors are:


ip setDefault


EXAMPLES See examples under tcp

SEE ALSO stream, protocol, ipx, udp, tcp


ipAddressTableA

NAME - ipAddressTableipAddressTable - configure the IP address table parameters for a port on a card on a chassis

SYNOPSIS ipAddressTable sub-command options

DESCRIPTION The ipAddressTable command is used to configure the IP address table-specific information used when building IP address table.

STANDARD OPTIONS

defaultGateway Default gateway IP address. (default = 0.0.0.0)

COMMANDS The ipAddressTable command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ipAddressTable addItem

Creates IP and MAC address ranges. Specific errors are:• The configured parameters are not valid for this port

ipAddressTable cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ipAddressTable command.

ipAddressTable clear

Clears the IP address table.

ipAddressTable config option valueModify the IP address table configuration options of the port. If no option is specified, returns a list describing all of the available ipAddressTable options (see STANDARD OPTIONS) for port.

ipAddressTable delItem

Deletes IP and MAC address ranges.

ipAddressTable get chasID cardID portID

Gets the current IP address table configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling ipAddressTable cget option value to get the value of the configuration option. Specific errors are:


ipAddressTable get chasID cardID portIDGets the IP address table configuration of the port with id portID on card cardID, chassis chasID.


ipAddressTable

ipAddressTable getFirstItem

Gets the first IP and MAC address range out of the IP address table. Specific errors are:

• There is no IP address table in the IP server• There are no more entries in the IP table

ipAddressTable getItem fromIp toIp fromMac toMacGets the IP address range from fromIP to toIp and MAC address range fromMac to toMac out of the IP address table. Specific errors are:


ipAddressTable getNextItem

Gets the next IP and MAC address range out of the IP address table. Specific errors are:


ipAddressTable set chasID cardID portIDSets the IP address table configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the ipAd-dressTable config option value command.

ipAddressTable setDefault


EXAMPLES See examples under arp.

SEE ALSO ip


ipAddressTableItemA

NAME - ipAddressTableItemipAddressTableItem - configure the IP address table parameters for a port on a card on a chassis

SYNOPSIS ipAddressTableItem sub-command options

DESCRIPTION The ipAddressTableItem command is used to configure the IP address table-specific information used when building IP address table.

STANDARD OPTIONS

enableUseNetwork If set, the netMask field is used to set the network mask; otherwise, the network mask is 0.0.0.0. (default = 0)

fromIpAddress The first IP address for the IP address range. (default = 0.0.0.0)

fromMacAddress The first MAC address for the MAC address range. (default = 00 00 00 00 00 00)

gatewayIpAddress Default gateway IP address. (default = 0.0.0.0)

mappingOption Specifies the mapping option. One of:

netMask If enableUseNetwork is set, this value is used to set the network mask. (default = 24).

numAddresses Number of consecutive addresses. (default = 1)

overrideDefaultGateway true/false

Enable default gateway IP address. (default =false)

toIpAddress Read-Only. Last IP address in the IP address range. (default = 0.0.0.0)

toMacAddress Read-Only. Last MAC address in the MAC address range.

(default = 00 00 00 00 00 00)

COMMANDS The ipAddressTableItem command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

ipAddressTableItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ipAddressTableItem command.

Option Value Usage

oneIpToOneMAC 0 (default)

manyIpToOneMAC 1


ipAddressTableItem

ipAddressTableItem config option valueModify the IP address table configuration options of the port. If no option is specified, returns a list describing all of the available ipAddressTableItem options (see STANDARD OPTIONS) for port.

ipAddressTableItem get

Gets the current IP address table item configuration. Call this command before calling ipAddressTableItem cget option value to get the value of the configura-tion option.

ipAddressTableItem set Sets the IP address table item configuration, by reading the configuration option values set by the ipAddressTableItem config option value command.

ipAddressTableItem setDefault


EXAMPLES See examples under arp.

SEE ALSO ipAddressTable


ipxA

NAME - ipxipx - configure the IPX parameters for a port on a card on a chassis

SYNOPSIS ipx sub-command options

DESCRIPTION The ipx command is used to configure the IPX-specific information used when building IPX-type packets if the protocol config –name has been set to ipx.

STANDARD OPTIONS

destNetwork The network number of the network to which the destination node belongs. (default = 00 00 00 00)

destNetworkCounterMode

Specifies how the destination network address will be incremented or decremented. NOTE: Setting the destNetworkCounterMode other then ipxIdle will take over one of the available UDFs. Possible values include:

destNetworkMaskSelect

Selects the bits in the 32-bit destination network address that are to be masked by the value set by destNetworkMaskValue. (default = 00 00 00 00)

destNetworkMaskValue Value of the masked bits selected by destNetworkMaskSelect in the destination network address. (default = FF FF FF FF)

destNetworkRepeatCounter

Number of destination network addresses the stream is going to be transmitted to. (default = 1)

destNode The physical address of the destination node. (default = 00 00 00 00 00 00)

destNodeCounterMode Specifies how the destination node will be incremented or decremented. NOTE: Setting the destNodeCounterMode other then ipxIdle will take over one of the available UDFs. Possible values include:

Option Value Usage

ipxIdle 0 (default) no change to network address regardless of destNetworkRepeatCounter

ipxIncrement 1 increment the network address for as many destNet-workRepeatCounter specified

ipxDecrement 2 decrement the network address for as many dest-NetworkRepeatCounter specified

ipxContIncrement 3 Continuously increment the network address for each frame

ipxContDecrement 4 Continuously decrement the network address for each frame

ipxCtrRandom 5 Generate random destination network address for each frame

Option Value Usage

ipxIdle 0 (default) no change to node regardless of destNo-deRepeatCounter


ipx

destNodeMaskSelect Selects the bits in the 48-bit destination node address that are to be masked by the value set by destNodeMaskValue. (default = 00 00 00 00 00 00)

destNodeMaskValue Value of the masked bits selected by destNodeMaskSelect in the destination node. (default = FF FF FF FF FF FF)

destNodeRepeatCounter

Number of destination nodes the stream is going to be transmitted to. (default = 1)

destSocket The socket address of the packet’s destination process. (default = 0x4000) Well defined addresses include:

destSocketCounterMode

Specifies how the destination socket will be incremented or decremented. NOTE: Setting the destSocketCounterMode other then ipxIdle will take over one of the available UDFs. Possible values include:

destSocketMaskSelect Selects the bits in destination socket address that are to be masked by the value set by destSocketMaskValue. (default = 00 00 )

destSocketMaskValue Value of the masked bits selected by destSocketMaskSelect in the destination socket. (default = FF FF)

ipxIncrement 1 increment the node for as many destNodeRepeat-Counter specified

ipxDecrement 2 decrement the node for as many destNodeRepeat-Counter specified

ipxContIncrement 3 Continuously increment the node for each frame

ipxContDecrement 4 Continuously decrement the node for each frame

ipxCtrRandom 5 Generate random destination node for each frame

Option Value Usage

Option Value Usage

socketNcp 1105 – 0x0451

socketSap 1106 – 0x0452

socketRipx 1107 – 0x0453

socketNetBios 1109 – 0x0455

socketDiagnostics 1110 – 0x0456

socketSerialization 1111 – 0x0457

Option Value Usage

ipxIdle 0 (default) no change to socket regardless of destSocket-RepeatCounter

ipxIncrement 1 increment the socket for as many destSocketRepeat-Counter specified

ipxDecrement 2 decrement the socket for as many destSocketRepeat-Counter specified

ipxContIncrement 3 Continuously increment the socket for each frame

ipxContDecrement 4 Continuously decrement the socket for each frame

ipxCtrRandom 5 Generate random destination socket for each frame


ipxA

destSocketRepeatCounter

Number of destination sockets the stream is going to be transmitted to. (default = 1)

length The length of the IPX header plus the length of the data. (default = 0)

lengthOverride true/false

Allows to change the length in ipx header. (default = false)

packetType This field indicates the type of service offered or required by the packet. Possible values include:

sourceNetwork The network number of the network to which the source node belongs. (default = 00 00 00 00)

sourceNetworkCounterMode

Specifies how the source network address will be incremented or decremented. NOTE: Setting the sourceNetworkCounterMode other then ipxIdle will take over one of the available UDFs. Possible values include:

sourceNetworkMaskSelect

Selects the bits in the 32-bit source network address that are to be masked by the value set by sourceNetworkMaskValue. (default = 00 00 00 00)

sourceNetworkMaskValue

Value of the masked bits selected by sourceNetworkMaskSelect in the source network address. (default = FF FF FF FF)

sourceNetworkRepeat-Counter

Number of source network addresses the stream is going to be transmitted to. (default = 1)

typeUnknown 0 – 0x00 Used for all packets not classified by any other type.

typeRoutingInfo 1 – 0x01 Routing Information Packet.

typeEcho 2 – 0x02 Echo

typeError 3 – 0x03 Error

typeIpx 4 – 0x04 (default) Service Advertising Packet.

typeSpx 5 – 0x05 Used for sequenced packets.

typeNcp 17 – 0x11 Used for NetWare Core Protocol Packets.

typeNetBios 20 – 0x14 Used for Novell netBIOS.

typeNdsNcp 104 – 0x68 Used for NetWare Core Protocol Packets.

Option Value Usage

ipxIdle 0 (default) no change to network address regardless of sourceNetworkRepeatCounter

ipxIncrement 1 increment the network address for as many sourceNetworkRepeatCounter specified

ipxDecrement 2 decrement the network address for as many sourceNetworkRepeatCounter specified

ipxContIncrement 3 Continuously increment the network address for each frame

ipxContDecrement 4 Continuously decrement the network address for each frame

ipxCtrRandom 5 Generate random source network address for each frame


ipx

sourceNode The physical address of the source node. (default = 00 00 00 00 00 00)

sourceNodeCounterMode

Specifies how the source node will be incremented or decremented. NOTE: Setting the sourceNodeCounterMode other then ipxIdle will take over one of the available UDFs. Possible values include:

sourceNodeMaskSelect Selects the bits in the 48-bit source node address that are to be masked by the value set by sourceNodeMaskValue. (default = 00 00 00 00 00 00)

sourceNodeMaskValue Value of the masked bits selected by sourceNodeMaskSelect in the source node. (default = FF FF FF FF FF FF)

sourceNodeRepeatCounter

Number of source nodes the stream is going to be transmitted to. (default = 1)

sourceSocket The socket address of the packet’s source process. (default = 0x4000) Well known addresses include:

sourceSocketCounterMode

Specifies how the source socket will be incremented or decremented. NOTE: Setting the sourceSocketCounterMode other then ipxIdle will take over one of the available UDFs. Possible values include:

Option Value Usage

ipxIdle 0 (default) no change to node regardless of sourceNo-deRepeatCounter

ipxIncrement 1 increment the node for as many sourceNodeRepeat-Counter specified

ipxDecrement 2 decrement the node for as many sourceNodeRepeat-Counter specified

ipxContIncrement 3 Continuously increment the node for each frame

ipxContDecrement 4 Continuously decrement the node for each frame

ipxCtrRandom 5 Generate random source node for each frame

Option Value Usage

socketNcp 1105 – 0x0451

socketSap 1106 – 0x0452

socketRipx 1107 – 0x0453

socketNetBios 1109 – 0x0455

socketDiagnostics 1110 – 0x0456

socketSerialization 1111 – 0x0457

Option Value Usage

ipxIdle 0 (default) no change to socket regardless of source-SocketRepeatCounter

ipxIncrement 1 increment the socket for as many sourceSocketRe-peatCounter specified

ipxDecrement 2 decrement the socket for as many

ipxContIncrement 3 Continuously increment the socket for each frame sourceSocketRepeatCounter specified

ipxContDecrement 4 Continuously decrement the socket for each frame

ipxCtrRandom 5 Generate random source socket for each frame


ipxA

sourceSocketMaskSelect

Selects the bits in source socket address that are to be masked by the value set by sourceSocketMaskValue. (default = 00 00)

sourceSocketMaskValue

Value of the masked bits selected by sourceSocketMaskSelect in the source socket. (default = FF FF)

sourceSocketRepeatCounter

Number of source sockets the stream is going to be transmitted to. (default = 1)

svrClientType This allows the port to act either as a NetWare server or client. If set to server, then the port may send out SAP broadcasts to announce itself. Possible values include:

transportControl The number of routers that the packet has passed through. (default = 0)

COMMANDS The ipx command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

ipx cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ipx command.

ipx config option valueModify the IPX configuration options of the port. If no option is specified, returns a list describing all of the available IPX options (see STANDARD OPTIONS) for port.

ipx decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. ipx cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid IPX frame

ipx get chasID cardID portID

Gets the current IPX configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling ipx cget option value to get the value of the configuration option. Specific errors are:


ipx set chasID cardID portIDSets the IPX configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the ipx config option value command. Specific errors are:

Option Value Usage

server 1

client 2 (default)


ipx


ipx setDefault



set host localhostixInitialize $hostset chas [ixGetChassisID $host]


stream setDefault

protocol setDefaultprotocol config -name ipxprotocol config -ethernetType ethernetII

ipx setDefault

ipx config -destNetwork {00 00 00 02}ipx config -destNetworkCounterMode ipxIdleipx config -sourceNetwork {00 00 00 01}ipx config -sourceNetworkCounterMode ipxIdle

ipx config -destNode {00 00 00 01 00 00}ipx config -destNodeRepeatCounter 16ipx config -destNodeCounterMode ipxDecrementipx config -sourceNode {00 00 00 00 00 00}ipx config -sourceNodeRepeatCounter 16ipx config -sourceNodeCounterMode ipxIncrement

ipx config -destSocket 5ipx config -sourceSocket 4ipx set $chas $card $port



SEE ALSO stream, protocol, ip, udp


isisInterfaceA

NAME - isisInterfaceisisInterface - configures an interface for an ISIS router.

SYNOPSIS isisInterface sub-command options

DESCRIPTION The isisInterface holds the information related to a single interface on the simu-lated router. Interfaces are added into the isisRouter interface list using the isis-Router addInterface command. Refer to “IS-IS” on page 3-24 for a discussion on ISIS testing with Ixia equipment. Refer to “isisInterface” on page 5-69 for an overview.

STANDARD OPTIONS

connectToDuttrue / false

If set, this IS-IS interface is directly connected to the DUT. (default = false)

deadIntervalLevel1dealIntervalLevel2

The dead interval used with the Level 1 or Level 2 aspect of the interface, expressed in seconds. Used to determine if neighbor routers are non-operational. (default = 30)

enable true / false If set, enables the use of this route range for the simulated router. (default = false)

helloIntervalLevel1helloIntervalLevel2

The hello interval used with the Level 1 or Level 2 aspect of the interface, expressed in seconds. Used to send regular messages to neighbor IS-IS routers. (default = 10)

interfaceId The OSI interface ID for this interface. (default = 00 00 00 00 00 00)

ipAddress The IP address for this interface. (default = 0.0.0.0)

ipMask The IP mask associated with the IP address for this interface. (default = 255.255.255.0)

level The IS-IS level associated with the interface, one of:

metric The cost metric associated with the route. (default = 10)

networkType Indicates the type of network attached to the interface: broadcast or point-to-point. One of:

Option Value Usage

isisLevel1 1 level 1 interface

isisLevel2 2 (default) level 2 interface

isisLevel1Level2 3 level 1 and level 2 interface

Options Value Usage

isisBroadcast 1 a broadcast network

isisPointToPoint 2 (default) a point to point network


isisInterface

priorityLevel1priorityLevel2

The priority level associated with the Level 1 or Level 2 aspect of the interface. This is used in master election. (default = X)

COMMANDS The isisInterface command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

isisInterface cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the isisInterface command.

isisInterface config option valueModify the configuration options of the isisInterface. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for isisInterface.

isisInterface setDefault


EXAMPLES See examples under isisServer.

SEE ALSO isisServer, isisRouter, isisRouteRange


isisRouterA

NAME - isisRouterisisRouter - configure an ISIS router

SYNOPSIS isisRouter sub-command options

DESCRIPTION The isisRouter command represents a simulated router. In addition to some iden-tifying options, it holds two lists for the router:

• Route ranges – routes to be advertised by the simulated router, con-structed in the isisRouteRange command.

• Interfaces – router interface, constructed in the isisInterface com-mand.

Routers defined in this command are added to an isisServer using the isisServer addRouter command. Refer to “IS-IS” on page 3-24 for a discussion on IS-IS testing with Ixia equipment. Refer to “isisRouter” on page 5-67 for an overview of this command.

STANDARD OPTIONS

areaAddressList The list of area addresses to use. Expressed as a Tcl list with commas separating the elements. (default = { })

enable true / false Enables the use of this router in the simulated ISIS network. (default = false)

maxNumberOfAddresses

The Number of Area Addresses permitted for this IS area. (default = 3)

routerId The ID of the router, usually the lowest IP address on the router. (default = 0.0.0.0)

COMMANDS The isisRouter command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

isisRouter addInterface interfaceLocalIdAdds the router interface described in the isisInterface command to the list of interfaces associated with the router. The interface’s entry in the list is given an identifier of interfaceLocalId. Specific errors are:

• The parameters in isisInterface are invalid• A router with this interfaceLocalId exists already in the list

isisRouter addRouteRange routeRangeLocalIdAdds the route range described in the isisRouteRange command to the list of route ranges associated with the router. The range’s entry in the list is given an identifier of routeRangeLocalId. Specific errors are:

• The parameters in isisRouteRange are invalid• A router with this routeRangeLocalId exists already in the list


isisRouter

isisRouter cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the isisRouter command.

isisRouter clearAllInterfaces

Deletes all of the router interfaces.

isisRouter clearAllRouteRanges

Deletes all of the route ranges.

isisRouter config option valueModify the configuration options of the isisRouter. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for isisRouter.

isisRouter delInterface interfaceLocalIdDeletes the router interface with an identifier of interfaceLocalId. Specific errors are:

• No router with this interfaceLocalId exists in the list

isisRouter delRouteRange routeRangeLocalIdDeletes the route range with an identifier of routeRangeLocalId. Specific errors are:

• No router with this routeRangeLocalId exists in the list

isisRouter getFirstInterface

Access the first interface in the list. The results may be accessed using the isisIn-terface command. Specific errors are:

• isisRouter select hasn’t been called• There are no interfaces in the list

isisRouter getFirstRouteRange

Access the first route range in the list. The results may be accessed using the isis-RouteRange command. Specific errors are:

• There are no route ranges in the list

isisRouter getInterface interfaceLocalIdAccesses the interface’s entry in the list with an identifier of interfaceLocalId. The router interface is accessed in the isisInterface command. Specific errors are:

• A router with this interfaceLocalId does not exist in the list

isisRouter getNextInterface

Access the next interface in the list. The results may be accessed using the isisIn-terface command. Specific errors are:

• isisRouter getFirstInterface hasn’t been called• There is no more interfaces in the list


isisRouterA

isisRouter getNextRouteRange

Access the next route range in the list. The results may be accessed using the isis-RouteRange command. Specific errors are:

• isisRouter getFirstRouteRange hasn’t been called• There is no more route ranges in the list

isisRouter getRouteRange routeRangeLocalIdAccesses the range’s entry in the list with an identifier of routeRangeLocalId. The router range is accessed in the isisRouteRange command. Specific errors are:

• A router with this routeRangeLocalId does not exist in the list

isisRouter setDefault


isisRouter setInterface interfaceLocalIdSets the values for the interface’s entry in the list with an identifier of interface-LocalId based on changes made through the isisInterface command. This com-mand can be used to change a running configuration and must be followed by an isisServer write command in order to send these changes to the Protocol Server. Specific errors are:


isisRouter setRouteRange interfaceLocalIdSets the values for the route range’s entry in the list with an identifier of inter-faceLocalId based on changes made through the isisRouteRange command. This command should be used to change a running configuration and must be fol-lowed by an isisServer write command in order to send these changes to the Pro-tocol Server. Specific errors are:



SEE ALSO isisServer, isisInterface, isisRouteRange


isisRouteRange

NAME - isisRouteRangeisisRouteRange -sets up the parameters associated with an ISIS router range.

SYNOPSIS isisRouteRange sub-command options

DESCRIPTION The isisRouteRange command describes an individual set of routes. Route ranges are added into isisRouter lists using the isisRouter addRouteRange command. Refer to “IS-IS” on page 3-24 for a discussion on ISIS testing with Ixia equip-ment. Refer to “isisRouteRange” on page 5-69 for an overview of this command.

STANDARD OPTIONS

enable true / false Enables the use of this route range for the simulated router. (default = false)


networkIpAddress The IP address of the routes to be advertised. (default = 0.0.0.0)

numberOfNetworks The number of prefixes to be advertised. (default = 0)

prefix The number of bits in the prefixes to be advertised. For example, a value of 24 is equivalent to a network mask of 255.255.255.0. (default = 0)

COMMANDS The isisRouteRange command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

isisRouteRange cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the isisRouteRange command.

isisRouteRange config option valueModify the configuration options of the isisRouteRange. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for isisRouteRange.

isisRouteRange setDefault



SEE ALSO isisServer, isisInterface, isisRouter


isisServerA

NAME - isisServerisisServer - access the ISIS component of the Protocol Server for a particular port.

SYNOPSIS isisServer sub-command options

DESCRIPTION The isisServer command is necessary in order to access the IS-IS Protocol Server for a particular port. The select sub-command must be used before all other IS-IS commands. Refer to “IS-IS” on page 3-24 for a discussion on ISIS testing with Ixia equipment. Refer to “isisServer” on page 5-66 for an overview.

STANDARD OPTIONS

None

COMMANDS The isisServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

isisServer addRouter routerLocalIdAdds the IS-IS router described in the isisRouter command to the list of routers associated with the port. The router’s entry in the list is given an identifier of routerLocalId. Specific errors are:

• isisServer select hasn’t been called• The router parameters in isisRouter are invalid• A router with this routerLocalId exists already in the list

isisServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the isisServer command.

isisServer clearAllRouters

Deletes all the ISIS routers in the list. Specific errors are: • isisServer select hasn’t been called• There is no router with this routerLocalId in the list

isisServer config option valueModify the configuration options of the isisServer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for isisServer.

isisServer delRouter routerLocalIdDeletes the ISIS router described that has an identifier of routerLocalId. Specific errors are:

• isisServer select hasn’t been called• There is no router with this routerLocalId in the list


isisServer

isisServer generateStreams chasID cardID portID actionGenerate streams creates additional streams for the indicated port and replaces the port’s current streams or adds it to the current streams depending on the action option:

A separate stream is generated for each enabled route range associated with each ISIS router; each stream covers the count of IP addresses associated with the route range. The characteristics of the generated streams are:


• Ethernet II encapsulation is used.• IPv4 framing is used.• The transmission rate is the port’s maximum rate.• Minimum frame sizes are used.• A data pattern of incrementing bytes (00 01 02 ...) is used.• The source MAC address is set from the value associated with the indicated

sending port.• The destination MAC address is set via an ARP lookup on the destination IP

address, which is set using UDF4.• A single burst of packets is sent per stream, with the count equal to the count of

addresses in the route range.• UDF4 or IP address controls are used to iterate through the count of addresses

in the route range; it should not be reprogrammed.

isisServer getFirstRouter

Access the first ISIS router in the list. The results may be accessed using the isis-Router command. Specific errors are:

• isisServer select hasn’t been called• There are no routers in the list

isisServer getNextRouter

Access the next ISIS router in the list. The results may be accessed using the isis-Router command. Specific errors are:

• isisServer select hasn’t been called• isisServer getFirstRouter hasn’t been called• There is no more routers in the list

isisServer getRouter routerLocalIdAccess the ISIS router with an identifier of routerLocalId. The results may be accessed using the isisRouter command. Specific errors are:

• isisServer select hasn’t been called• There is no router with this routerLocalId in the list

isisServer select chasID cardID portIDAccesses the ISIS component of the Protocol server for the indicated port. Spe-cific errors are:

• No connection to the chassis• The ISIS protocol package has not been installed• Invalid port specified

Option Value Usage




isisServerA

isisServer setRouter routerLocalIdSets the values for the router’s entry in the list with an identifier of routerLocalId based on changes made through the isisRouter command. This command should be used to change a running configuration and must be followed by an isisServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A router with this routerLocalId does not exist in the list

isisServer write

Sends any changes made with isisRouter setInterface, isisRouter setRouteRange or isisServer setRouter to the Protocol Server for immediate application. This command must be used after those mentioned above in order for their changes to have an effect.


# Define parameters used by ISIS routerset host rubyif [ixInitialize $host] { logMsg “Error in connecting to hostName” return 1}

# Port is card 9, port 1set ch [chassis cget -id]set ca 9set po 4set pl [list [list $ch $ca $po]]set myMac {00 0a de 01 01 01}set router 101.101.12.2set neighbor 101.101.12.1set interfaceIpMask 255.255.255.0set numberOfRoute 1650

# Set up IP address table for others who ARP to usipAddressTableItem setDefault ipAddressTableItem config -numAddresses 1ipAddressTableItem config -mappingOption oneIpToOneMACipAddressTableItem config -overrideDefaultGateway falseipAddressTableItem config -fromIpAddress $routeripAddressTableItem config -fromMacAddress $myMacipAddressTable addItemipAddressTable config -defaultGateway $neighboripAddressTable set $ch $ca $po

# Select port to operateisisServer select $ch $ca $po

# Clear all routers isisServer clearAllRouters

# Configure the interfaceisisInterface setDefault isisInterface config -enable trueisisInterface config -connectToDut trueisisInterface config -ipAddress $routerisisInterface config -ipMask $interfaceIpMaskisisInterface config -networkType isisBroadcast


isisServer

isisInterface config -metric 10isisInterface config -level isisLevel2

# Add the isis interface to the routerif [isisRouter addInterface interface1] { logMsg “Error in adding isisInterface interface1”}

# Configure the routeRangeisisRouteRange setDefault isisRouteRange config -enable trueisisRouteRange config -metric 1isisRouteRange config -numberOfNetworks $numberOfRouteisisRouteRange config -prefix 24isisRouteRange config -networkIpAddress {14.0.0.0}

# Add the isis routeRange to the routerif [isisRouter addRouteRange routeRange1] { logMsg “Error in adding routeRange”}

# Configure isis routerisisRouter setDefault isisRouter config -routerId “00 0$ca 0$po 01 00 00”isisRouter config -enable true

# Add the router to the serverif [isisServer addRouter router1] { logMsg “Error in adding router”}

# Let the protocol server respond to ARP, ISIS and PINGprotocolServer config -enableArpResponse trueprotocolServer config -enableIsisService trueprotocolServer config -enablePingResponse falseprotocolServer set $ch $ca $po

# Send the data to the hardwarelogMsg “Writing the configuration to the hardware”ixWriteConfigToHardware pl

# And start ISIS on the portlogMsg “Start isis server ...”ixStartIsis pl

# Disable routeRange1 while isis server is runnung. # This is the same as removing the route range from router

isisServer select $ch $ca $po

if [isisServer getRouter router1] { logMsg “Error getting router1”}if [isisRouter getRouteRange routeRange1] { logMsg “Error getting routeRange1”}

# Disable the route range # (You can also change other configuration if you want)isisRouteRange config -enable false

if [isisRouter setRouteRange routeRange1] {


isisServerA

logMsg “Error setting routeRange1”}if [isisServer write] {

logMsg “Error writing isisServer”}

after 10000# Stop the server at the endlogMsg “Stop isis server ...”ixStopIsis pl

# If you wanted to add a route range while isis server is running, # -Configure it disabled before starting isis server and then# enable it# The same thing is also possible on isisInterface.# You just need to get the item that you want and change the configuration# and set that item. Then write the changes to hardware by isisServ

SEE ALSO isisInterface, isisRouter, isisRouteRange


isl

NAME - islisl - configure the Cisco Inter-Switch Link (ISL) parameters for a port on a card on a chassis

SYNOPSIS isl sub-command options

DESCRIPTION The isl command is used to configure the ISL-specific information used when building ISL-type packets. This is enabled using protocol config -enableISLtag true. The encapsulated frame’s Source and Destination MAC addresses are con-figured through the stream config -da and -sa commands. See “stream” on page A-282. The previously documented options to the isl command encapDA and encapSA, should not be used to set the MAC addresses but may be used to view the values.

STANDARD OPTIONS

bpdu Set for all Bridge Protocol Data Units that are encapsulated by the ISL packet. (default = 0)

encapDA The encapulated frame's Destination MAC addresses. This value should be set through the use of stream config -da, but may be read back through this option. For example:

stream config -da {02 02 02 02 02 02}stream config -sa {01 01 01 01 01 01}stream set 1 1 1 1isl get 1 1 1isl cget -encapDA02 02 02 02 02 02isl cget -encapSA01 01 01 01 01 01

encapSA The encapulated frame's Source MAC addresses. This value should be set through the use of stream config -sa, but may be read back through this option. See the exampel for encapDA.

frameType The type field indicates the type of frame that is encapsulated. Options include:

hsa The High bits of Source Address is the upper 3 bytes of the Source Address, which corresponds to the manufacturer's ID. (default = 00 00 0C)

index Value of the selected register. (default = 0)

Option Value Usage

islFrameEthernet 0 (default)

islFrameTokenRing 1

islFrameFDDI 2

islFrameATM 3


islA

islDA The address is a multicast address whose value in the first 40 bits of the DA indicate to the receiver that the packet is in ISL format. (default = 01 00 0C 00 00)

islSA Read-Only: The source MAC address. The upper 3 bytes of this field are reflected in the hsa field. (default = 00 00 0C 00 00 00)

userPriority The low order two bits of this field indicate the priority of the packet as it passes through the switch. Priorities 0 to 7 are valid. (default = 0)

vlanID The Virtual LAN Identifier. (default = 1)

COMMANDS The isl command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

isl cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the isl command.

isl config option valueModify the ISL configuration options of the port. If no option is specified, returns a list describing all of the available ISL options (see STANDARD OPTIONS) for port.

isl decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. isl cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid ISL frame

isl get chasID cardID portIDGets the current ISL configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling isl cget option to get the value of the configuration option. Specific errors are:


isl set chasID cardID portIDSets the ISL configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the isl config option value command. Specific errors are:


isl setDefault



isl




stream setDefault

protocol setDefaultprotocol config -name ipV4protocol config -ethernetType ethernetIIprotocol config -enableISLtag true

isl setDefaultisl config -vlanID 42isl set $chas $card $port



SEE ALSO protocol


miiA

NAME - miimii - configure the MII parameters for a MII ports

SYNOPSIS mii sub-command options

DESCRIPTION The mii command is used to configure the MII-specific information on old-style IEEE 802.3 devices. New style MII AE devices defined in IEEE 802.3ae are managed by the miiae, mmd, and mmdRegister commands.

STANDARD OPTIONS

enableManualAutoNegotiate true / false

If set to true, then as the MII register is written to hardware auto negotiation will begin. (default = false)

miiRegister MII Source register. Defined register values include:

Option Value Usage

miiControl 0 (default)

miiStatus 1

miiPHYId1 2

miiPHYId2 3

miiAutoNegAdvertisement 4

miiAutoNegLinkPartnerAbility 5

miiAutoNegExpansion 6

miiRegister7 7

miiRegister8 8

miiRegister9 9

miiRegister10 10

miiRegister11 11

miiRegister12 12

miiRegister13 13

miiRegister14 14

miiRegister15 15

miiMirror 16

miiInterruptEnable 17

miiInterruptStatus 18

miiConfiguration 19

miiChipStatus 20

miiRegister21 21

miiRegister22 22

miiRegister23 23

miiRegister24 24

miiRegister25 25

miiRegister26 26


mii

phyAddress Physical address of the MII register location. If set to –1, use default location. (default = -1)

readWrite Sets the properties of the selected register. Possible properties include:

registerValue Value of the selected register. (default = 0000)

COMMANDS The mii command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

mii cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the mii command.

mii config option valueModify the MII configuration options of the port. If no option is specified, returns a list describing all of the available MII options (see STANDARD OPTIONS) for port.

mii get chasID cardID portID [index = 0]Gets the current MII configuration of the port with id portID on card cardID, chassis chasID. Any of the three supported PHYs may be selected through the use of the index. The supported PHYs are:

Call this command before calling mii cget option value to get the value of the configuration option. Specific errors are:


miiRegister27 27

miiRegister28 28

miiRegister29 29

miiRegister30 30

miiRegister31 31

Option Value Usage

Option Value Usage

miiDisabled 0 (default)

miiReadOnly 1

miiReadWrite 2

miiSynchToCurrentState 3 The register is read and written during operation. In addition, the read values are placed into the editable fields at the same time.

Option Value Usage

mdioInternal 0 (default) The internal PHY located on the Ixia card.

mdioExternal1 1 The first defined external PHY.

mdioExternal2 2 The second defined external PHY.


miiA

• The port is being used by another user• Network error between the client and the chassis

mii selectRegister selectAfter mii get chasID cardID portID has completed selects which register to fill the Tcl parameters with. Specific errors are:

• No port has previously been selected with the mii.get method• The port is not an Mii port, or a port with Mii capability

mii set chasID cardID portID [index = 0]Sets the MII configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the mii config option value command. Any of the three supported PHYs may be set through the use of the index. The supported PHYs are:

Specific errors are:• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• The port is not an Mii port, or a port with Mii capability

mii setDefault


mii write chasID cardID portIDWrites the MII configuration of the port with id portID on card cardID, chassis chasID to the hardware. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Network error between the client and the chassis• The port is not an Mii port, or a port with Mii capability


# Connect to chassis and get chassis IDset host localhostixInitialize $hostset chas [ixGetChassisID $host]# Assuming that MII card is in slot 3set card 3

# Check for missing cardif {[card get $chas $card] != 0} \{ ixPuts “Card $card does not exist” exit

Option Value Usage





mii

}

# Get the type of card and check if it’s the correct typeset cardType [card cget -type]if {$cardType != $::card10100Mii} \{ ixPuts “Card $card is not a 10/100 MII card” exit}

# Set the options to default valuesmii setDefault

# Get the current mii state from the cardmii get $chas $card 1

# Get the value of the control register (0)mii selectRegister miiControlset controlReg [mii cget -registerValue]set msg [format “Register 00 value is %04x” $controlReg]ixPuts $msg

# Set the mode on register 00 to Read/Write/Syncmii config -readWrite miiSynchToCurrentState# With bit 14 (loopback) onset controlReg [expr $controlReg | 0x0400]mii config -registerValue $controlReg

# set to ixTclHalmii set $chas $card 1

# and write to hardwareset portList [list [list $chas $card 1]]ixWritePortsToHardware portList

SEE ALSO port, miiae, mmd, mmdRegister


miiaeA

NAME - miiaemiiae - configure an MII AE.

SYNOPSIS miiae sub-command options

DESCRIPTION The miiae command is used to configure an MII AE PHY to be associated with a port. miiae manages new-style IEEE 802.3ae PHYs. After configuration, miiae set should be used to associate it with a port; port write or miiae write should be used to write the values to the hardware.

STANDARD OPTIONS

phyAddress The address of the MII AE PHY. (default = 0)

COMMANDS The miiae command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

miiae addDevice

Adds the device defined through the use of the mmd command.

miiae clearAllDevices

Deletes all devices associated with this MII AE PHY.

miiae config option valueModify the configuration options of the PHY. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS).

miiae delDevice deviceAddressDeletes the device whose address is deviceAddress.

miiae get chasID cardID portID indexGets the current MII configuration of the port with id portID on card cardID, chassis chasID. Any of the three supported PHYs may be selected through the use of the index. The supported PHYs are:

Call this command before calling mmd to look at the PHY. Specific errors are:• No connection to a chassis• Invalid port number• The port is being used by another user• Network error between the client and the chassis

Option Value Usage





miiae

miiae getDevice deviceAddressGets the device whose address is deviceAddress. The values associated with the device may be viewed and modified through the use of the mmd command.

miiae set chasID cardID portID indexSets the MII configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the mmd command. Any of the three supported PHYs may be set through the use of the index. The supported PHYs are:

Specific errors are:• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• The port is not an Mii port, or a port with Mii capability

miiae setDefault



# Connect to chassis and get chassis IDset host localhostixInitialize $hostset chas [ixGetChassisID $host]# Assuming that a 10GB XAUI card is in slot 3set card 48set port 1set deviceNo 1

# Configure register 1mmdRegister config -address 1mmdRegister config -name reg1mmdRegister config -registerValue {12 23}# And add it to the MMDmmd addRegister

# Configure register 1mmdRegister config -address 2mmdRegister config -name reg2mmdRegister config -registerValue {34 05}mmd addRegister

# Now configure the MMD and add it to the miiaemmd config -address $deviceNommd config -name dev1# Add it to the miiaemiiae addDevice

Option Value Usage





miiaeA

miiae config -phyAddress 24

# Set and write the miiaeif [miiae set $chas $card $port mdioExternal1] { ixPuts “Error in miiae set”}if [miiae write $chas $card $port] { ixPuts “Error in miiae write”}

# Now get the object backmiiae clearAllDevicesif [miiae get $chas $card $port mdioExternal1] { ixPuts “Error in miiae get”}if [miiae getDevice $deviceNo] { ixPuts “Error in miiae getDevice”}

# Now get the register contentsmmd getRegister 1set name [mmdRegister cget -name]set val [mmdRegister cget -registerValue]ixPuts “Register 1 ($name) is $val”

SEE ALSO mii, mmd, mmdRegister


mmd

NAME - mmdmmd - configure an MII AE PHY.

SYNOPSIS mmd sub-command options

DESCRIPTION The mmd command is used to configure an individual MII AE PHY device. After configuration, miiae addDevice should be used to add the device to the MII AE. The current contents of the device may be obtained via miiae getDevice. The value of a device may only be changed by a sequence of miiae getDevice, miiae delDevice and miiae addDevice.

STANDARD OPTIONS

address The address of the device in the MMD device. (default = 0)

name The name of the device. (default = {})

COMMANDS The mmd command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

mmd addRegister

Adds the register defined through the use of the mmdRegister command to the MMD device.

mmd clearAllRegisters

Deletes all the registers associated with the MMD device.

mmd config option valueModify the configuration options of the MMD device. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS).

mmd delRegister registerAddressDeletes the register whose address is registerAddress.

mmd getRegister registerAddressGets the register whose address is registerAddress. The values associated with the register may be viewed and modified through the use of the mmdRegister command.

mmd setDefault


EXAMPLES See examples in miiae.

SEE ALSO mii, miiae, mmdRegister


mmdRegisterA

NAME - mmdRegistermmdRegister - configure an MII AE MMD Register.

SYNOPSIS mmdRegister sub-command options

DESCRIPTION The mmdRegister command is used to configure an individual MII AE MMD register. After configuration, mmd addRegister should be used to add the register to the PHY device. The current contents of the register may be obtained via mmd getRegister. The value of a register may only be changed by a sequence of mmd getRegister, mmd delRegister and mmd addRegister.

STANDARD OPTIONS

address The address of the register in the register. (default = 0)

name The name of the register. (default = {})

readWrite Sets the properties of the selected register. Possible properties include:

registerValue Value of the selected register. (default = 0)

COMMANDS The mmdRegister command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

mmdRegister config option valueModify the configuration options of the register. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS).

mmdRegister setDefault


EXAMPLES See examples in miiae.

SEE ALSO mii, miiae, mmd

Option Value Usage

miiDisabled 0

miiReadOnly 1

miiReadWrite 2 (default)

miiSynchToCurrentState 3 The register is read and written during operation. In addition, the read values are placed into the editable fields at the same time.


mpls

NAME - mplsmpls - configure the MPLS parameters for a port on a card on a chassis

SYNOPSIS mpls sub-command options

DESCRIPTION The mpls command is used to configure the MPLS information when building MPLS labeled packets. See draft-ietf-mpls-arch-06.txt “work in progress” for a complete definition of MPLS label fields.

STANDARD OPTIONS

forceBottomOfStack true/false

Automatically sets bottom of the stack bit. (default = true)

type Sets the MPLS type. Options include:

COMMANDS The mpls command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

mpls cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the mpls command.

mpls config option valueModify the MPLS configuration options of the port. If no option is specified, returns a list describing all of the available MPLS options (see STANDARD OPTIONS) for port.

mpls decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. mpls cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:

• No connection to a chassis• Invalid port number• The captured frame is not a valid Mpls frame

mpls get chasID cardID portIDGets the current MPLS configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling mpls cget option to get the value of the configuration option. Specific errors are:


Option Value Usage

mplsUnicast 0 (default)

mplsMulticast 1


mplsA

• Invalid port number

mpls set chasID cardID portIDSets the MPLS configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the mpls config option value command. Specific errors are:


mpls setDefault




set card 1set txPort 1set rxPort 2



# Nothing special about the portsport setFactoryDefaults $chas $card $txPortport setDefaultport set $chas $card $txPortport set $chas $card $rxPort

# Stream: 10 packetsstream setDefaultstream config -numFrames 10stream config -dma stopStream#stream config -percentPacketRate 100#stream config -rateMode usePercentRate

protocol setDefaultprotocol config -ethernetType ethernetIIprotocol config -enableMPLS true

# Setup up two mpls labelsmpls setDefaultmpls config -type mplsUnicast

mplsLabel setDefaultmplsLabel config -label 128mplsLabel config -bottomOfStack falsemplsLabel set 1

mplsLabel config -label 256


mpls

mplsLabel config -bottomOfStack truemplsLabel set 2

mpls set $chas $card $txPort

stream set $chas $card $txPort 1


# Make sure link is upafter 1000ixCheckLinkState portListixStartPortCapture $chas $card $rxPort

# Clear stats and transmit MPLS labeled framesixClearStats portListixStartPortTransmit $chas $card $txPort

SEE ALSO stream, protocol, mplsLabel


mplsLabelA

NAME - mplsLabelmplsLabel - configure the MPLS label parameters for a port on a card on a chas-sis.

SYNOPSIS mplsLabel sub-command options

DESCRIPTION The mplsLabel command is used to configure the MPLS label information when building MPLS labeled packets. See draft-ietf-mpls-arch-06.txt “work in progress” for a complete definition of MPLS label fields.

STANDARD OPTIONS

bottomOfStack true/false

Enables the bottom of the stack bit. This bit is set to true for the last entry in the label stack (for the bottom of the stack) and false for all other label stack entries. (default = true)

experimentalUse Sets the experimental use. (default=0)

label Sets the actual value of the label. Any 16-bit value is valid; predefined options include:

timeToLive Sets the time-to-live value. (default=0)

COMMANDS The mplsLabel command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

mplsLabel cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the mplsLabel command.

mplsLabel config option valueModify the MPLS label configuration options of the port. If no option is speci-fied, returns a list describing all of the available MPLS label options (see STAN-DARD OPTIONS) for port.

mplsLabel get labelIDGets the current label configuration of the selected labelID. Call this command before calling mplsLabel cget option to get the value of the configuration option. Specific errors are:

Option Value Usage

mplsIPv4ExplicitNULL 0 (default)

mplsRouterAlert 1

mplsIPv6ExplicitNULL 2

mplsImplicitNULL 3

mplsReserved 4


mplsLabel

• There are no MPLS labels• The specified labelID does not exist

mplsLabel set labelIDSets the label configuration for label labelID reading the configuration option values set by the mplsLabel config option value command. Specific errors are:

• The configured parameters are not valid for this port• Insufficient memory to add a new label

mplsLabel setDefault


EXAMPLES See examples under the mpls command.

SEE ALSO stream, protocol, mpls


ospfInterfaceA

NAME - ospfInterfaceospfInterface - configures an interface for an OSPF router.

SYNOPSIS ospfInterface sub-command options

DESCRIPTION The ospfInterface holds the information related to a single interface on the simu-lated router. Interfaces are added into the ospfRouter interface list using the osp-fRouter addInterface command. Refer to “OSPF” on page 3-17 for a discussion on OSPF testing with Ixia equipment. Refer to “ospfInterface” on page 5-62 for an overview.

STANDARD OPTIONS

areaId The OSPF area ID associated with the interface. (default = 0)

connectToDut Indicates that this interface is directly connected to the DUT. (default = 0)

deadInterval The time after which the DUT router is considered dead if it does not send HELLO messages. (default = 40)

enable Enables the use of the simulated interface. (default = 0)

enableTrafficEngineering true / false

Enables the use of the linkMetric, maxBandwidth, maxReservableBandwidth, and unreservedBandwidthPriority0-7 for traffic engineering purposes. These values are used to generate two LSAs: a router LSA and a link LSA with an opaque TLV containing sub-TLV for the link metric, max bandwidth, max reservable band-width and unreserved bandwidth priorities. (default = false)

enableValidateMtu true / false

Enables validation on incoming database entries received by the simulated router. If this is set to 1, then received database entries which advertise an MTU larger than the value in the mtuSize option are ignored. If this is set to 0, then the adver-tised MTU size is 0 and the MTU size in received database entries is ignored. (default = true)

helloInterval The time between HELLO messages sent over the interface. (default = 10)

ipAddress The IP address of the interface. (default = 0.0.0.0)

ipMask The IP mask associated with the interface. (default = 255.255.255.0)

linkMetric If enableTrafficEngineering is true, then this indicates the traffic engineering metric associated with the interface. (default = 0)

linkType The Link Type advertised in the Router LSA interface list. One of the following:

Option Value Usage

ospfInterfaceLinkPointToPoint 1 A point-to-point network.

ospfInterfaceLinkTransit 2 (default) A transit network.

ospfInterfaceLinkStub 3 A stub network.


ospfInterface

maxBandwidth If enableTrafficEngineering is ‘1’, then this indicates the maximum bandwidth that can be used on the link between this interface and its neighbors in the out-bound direction. (default = 0.0)

maxReservableBandwidth

If enableTrafficEngineering is ‘1’, then this indicates the maximum bandwidth, in bytes per second, that can be reserved on the link between this interface and its neighbors in the outbound direction. (default = 0.0)

metric The metric associated with the interface. (default = 10)

neighborRouterId When the linkType option is set to ospfInterfaceLinkPointToPoint, then this option should be set to the ID of the router on the other end of the point-to-point connection. (default = 0.0.0.0)

networkType Indicates the type of network associated with the interface. One of the following options:

numberOfLearnedLsas Read-only. The number of learned LSAs obtained through a call to ospfInterface getLearnedLsaList.

mtuSize The advertised MTU value in database entries sent to other routers. The enableValidateMTU option must be set to true in order for the MTU size to be transmitted. (default = 1500)

options Options related to the interface. Multiple options may be or’d together. The available options are:

priority The priority of the interface, for use in election of the designated or backup master. (default = 0)

unreservedBandwidthPriority0-7

If enableTrafficEngineering is ‘1’, then these eight values indicate the amount of bandwidth, in bytes per second, not yet reserved at each of the eight priority lev-els. These values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7. Each value must be less than the maxReservableBandwidth option. (default = 0.0)

Option Value Usage

ospfPointToPoint 1 Indicates that the network is point to point, as in a PPP connection.

ospfBroadcast 2 (default) Indicates that the network is a broadcast network, as in an Ethernet connection.

Option Value Usage

ospfOptionBitTypeOfService 0x01

ospfOptionBitExternalRouting 0x02 default

ospfOptionBitMulticast 0x04

ospfOptionBitNSSACapability 0x08

ospfOptionBitExternalAttributes 0x10

ospfOptionBitDemandCircuit 0x20

ospfOptionBitLSANoForward 0x40

ospfOptionBitUnused 0x80


ospfInterfaceA

COMMANDS The ospfInterface command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ospfInterface cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfInterface command.

ospfInterface config option valueModify the configuration options of the ospfInterface. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfInterface.

ospfInterface getFirstLearnedLsa

This command must be preceded by use of the ospfInterface getLearnedLsaList command and followed by multiple uses of ospfInterface getNextLearnedLsa. This command fetches the first of the learned LSAs in the list into memory. The data associated with the individual LSA may be read through the use of the ospfUserLsa command.

ospfInterface getLearnedLsaList

This command must be preceded by use of the ospfInterface requestLearnedLsaList and followed by a call to ospfInterface getFirstLearn-edLsa. This command determines whether the reading of learned LSAs from the Protocol Server has completed. This command should be called until it returns a ‘0’, or until some suitable period of time has elapsed. The number of learned LSAs is available in the numberOfLearnedLsas option.

ospfInterface getNextLearnedLsa

This command must be preceded by use of the ospfInterface getFirstLsa com-mand and repeated multiple times to obtain all of the learned LSAs. This com-mand fetches the next of the learned LSAs in the list into memory. The data associated with the individual LSA may be read through the use of the ospfU-serLsa command.

ospfInterface requestLearnedLsa

Requests that the learned LSAs associated with this interface be retrieved from the Protocol Server. This command must be followed by call to ospfInterface getLearnedLsaList.

ospfInterface setDefault


EXAMPLES See examples under ospfServer

SEE ALSO ospfServer, ospfRouter, ospfRouteRange, ospfUserLsaGroup, ospfUserLsa, osp-fRouterLsaInterface


ospfRouter

NAME - ospfRouterospfRouter - configure an OSPF router

SYNOPSIS ospfRouter sub-command options

DESCRIPTION The ospfRouter command represents a simulated router. In addition to some iden-tifying options, it holds three lists for the router:

• Route ranges – routes to be advertised by the simulated router, con-structed in the ospfRouteRange command.

• Interfaces – router interface, constructed in the ospfInterface com-mand.

• LSA Groups – Link State Advertising Groups which will be associ-ated with advertised routes, constructed in the ospfUserLSAGroup command and subsidiary commands.

Routers defined in this command are added to an ospfServer using the ospfServer addRouter command. Refer to “OSPF” on page 3-17 for a discussion on OSPF testing with Ixia equipment. Refer to “ospfRouter” on page 5-59 for an overview of this command.

STANDARD OPTIONS

autoGenerateRouterLsatrue / false

If enabled, the router will automatically generate a router LSA including all of the interfaces added with the ospfRouter addInterface command. This should be turned off if you are building OSPF topologies with ospfUserLsa commands. (default = true)

enable true / false Enables the use of this router in the simulated OSPF network. (default = false)

routerId ID of the router, usually the lowest IP address on the router. (default = 0.0.0.0)

COMMANDS The ospfRouter command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ospfRouter addInterface interfaceLocalIdAdds the router interface described in the ospfInterface command to the list of interfaces associated with the router. The interface’s entry in the list is given an identifier of interfaceLocalId. Specific errors are:

• The parameters in ospfInterface are invalid• A router with this interfaceLocalId exists already in the list

ospfRouter addRouteRange routeRangeLocalIdAdds the route range described in the ospfRouteRange command to the list of route ranges associated with the router. The range’s entry in the list is given an identifier of routeRangeLocalId. Specific errors are:

• The parameters in ospfRouteRange are invalid• A router with this routeRangeLocalId exists already in the list


ospfRouterA

ospfRouter addUserLsaGroup userLsaGroupLocalIdAdds the user LSA group described in the ospfUserLsaGroup command to the list of user LSAs associated with the router. The LSA’s entry in the list is given an identifier of userLsaGroupLocalId. Specific errors are:

• The parameters in ospfUserLsaGroup are invalid• A router with this UserLsaGroupLocalId exists already in the list

ospfRouter cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfRouter command.

ospfRouter clearAllInterfaces

Deletes all of the router interfaces.

ospfRouter clearAllLsaGroups

Deletes all of the user LSA groups.

ospfRouter clearAllRouteRanges


ospfRouter config option valueModify the configuration options of the ospfRouter. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfRouter.

ospfRouter delInterface interfaceLocalIdDeletes the router interface with an identifier of interfaceLocalId. Specific errors are:

• No router with this interfaceLocalId exists in the list

ospfRouter delRouteRange routeRangeLocalIdDeletes the route range with an identifier of routeRangeLocalId. Specific errors are:

• No router with this routeRangeLocalId exists in the list

ospfRouter delUserLsaGroup userLsaGroupLocalIdDeletes the user LSA group with an identifier of userLsaGroupLocalId. Specific errors are:

• No router with this UserLsaGroupLocalId exists in the list

ospfRouter getFirstInterface

Access the first interface in the list. The results may be accessed using the osp-fRouter command. Specific errors are:

• ospfRouter select hasn’t been called• There are no interfaces in the list


ospfRouter

ospfRouter getFirstRouteRange

Access the first route range in the list. The results may be accessed using the osp-fRouter command. Specific errors are:


ospfRouter getFirstUserLsaGroup

Access the first user LSA group in the list. The results may be accessed using the ospfRouter command. Specific errors are:

• There are no user LSA groups in the list

ospfRouter getInterface interfaceLocalIdAccesses the interface’s entry in the list with an identifier of interfaceLocalId. The router interface is accessed in the ospfInterface command. Specific errors are:


ospfRouter getNextInterface

Access the next interface in the list. The results may be accessed using the osp-fRouter command. Specific errors are:

• ospfRouter getFirstInterface hasn’t been called• There is no more interfaces in the list

ospfRouter getNextRouteRange

Access the next route range in the list. The results may be accessed using the osp-fRouter command. Specific errors are:

• ospfRouter getFirstRouteRange hasn’t been called• There is no more route ranges in the list

ospfRouter getNextUserLsaGroup

Access the next user LSA group in the list. The results may be accessed using the ospfRouter command. Specific errors are:

• ospfRouter getFirstUserLsaGroup hasn’t been called• There is no more user LSA groups in the list

ospfRouter getRouteRange routeRangeLocalIdAccesses the range’s entry in the list with an identifier of routeRangeLocalId. The router range is accessed in the ospfRouteRange command. Specific errors are:

• A route range with this routeRangeLocalId does not exist in the list

ospfRouter getUserLsaGroup userLsaGroupLocalIdAccesses the user LSA group’s entry in the list with an identifier of userLsa-GroupLocalId. The group is accessed in the ospfUserLsaGroup command. Spe-cific errors are:

• A router with this userLsaGroupLocalId does not exist in the list

ospfRouter setDefault



ospfRouterA

ospfRouter setInterface interfaceLocalIdSets the values for the interface’s entry in the list with an identifier of interfaceLocalId based on changes made through the ospfInterface command. This command can be used to change a running configuration and must be fol-lowed by an ospfServer write command in order to send these changes to the Pro-tocol Server. Specific errors are:

• An interface with this interfaceLocalId does not exist in the list

ospfRouter setRouteRange routeRangeLocalIdSets the values for the route range’s entry in the list with an identifier of routeRangeLocalId based on changes made through the ospfRouteRange com-mand. This command can be used to change a running configuration and must be followed by an ospfServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A router range with this routeRangeLocalId does not exist in the list

ospfRouter setUserLsaGroup userLsaGroupLocalIdSets the values for the user LSA group’s entry in the list with an identifier of userLsaGroupLocalId based on changes made through the ospfUserLsaGroup command. This command can be used to change a running configuration and must be followed by an ospfServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A user LSA group with this userLsaGroupLocalId does not exist in the list


SEE ALSO ospfServer, ospfInterface, ospfRouteRange, ospfUserLsaGroup, ospfUserLsa, ospfRouterLsaInterface


ospfRouteRange

NAME - ospfRouteRangeospfRouteRange -sets up the parameters associated with an OSPF router range.

SYNOPSIS ospfRouteRange sub-command options

DESCRIPTION The ospfRouteRange command describes an individual set of routes. Route ranges are added into ospfRouter lists using the ospfRouter addRouteRange com-mand. Refer to “OSPF” on page 3-17 for a discussion on OSPF testing with Ixia equipment. Refer to “ospfRouteRange” on page 5-61 for an overview.

STANDARD OPTIONS

enable true / false Enables the use of this route range for the simulated router. (default = false)


networkIpAddress The IP address of the routes to be advertised. (default = 0.0.0.0)

numberOfNetworks The number of prefixes to be advertised. (default = 0)

prefix The number of bits in the prefixes to be advertised. For example, a value of 24 is equivalent to a network mask of 255.255.255.0. (default = 0)

routeOrigin Whether the route originated within the area or externally. One of:

COMMANDS The ospfRouteRange command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ospfRouteRange cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfRouteRange command.

ospfRouteRange config option valueModify the configuration options of the ospfRouteRange. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfRouteRange.

ospfRouteRange setDefault



SEE ALSO ospfServer, ospfInterface, ospfRouter, ospfUserLsaGroup, ospfUserLsa, osp-fRouterLsaInterface

Option Value Usage

ospfRouteOriginArea 0 (default) within the area

ospfRouteOriginExternal 1 from outside the area

ospfRouteOriginExternalType2 2 from outside the area, but with metrics which are larger than any internal metric


ospfRouterLsaInterfaceA

NAME - ospfRouterLsaInterfaceospfRouterLsaInterface - configure a single Router LSA Interface entry.

SYNOPSIS ospfRouterLsaInterface sub-command options

DESCRIPTION The ospfRouterLSAInterface command describes a single Router LSA Interface entry. The data from this entry is added to an ospfUserLsa list for a RouterLSA entry using the ospfUserLsa addInterfaceDescriptionToRouterLsa command. Refer to “OSPF” on page 3-17 for a discussion on OSPF testing with Ixia equipment. Refer to “ospfRouterLSAInterface” on page 5-65 for an overview of this com-mand.

STANDARD OPTIONS

linkData Depends on the linkType field: (default = 0.0.0.0)

linkId Identifies the object that this router link connects to, depending on the linkType field: (default = 0.0.0.0)

linkType The type of the router link. One of:

metric The cost of using the router link, applied to all TOS values.(default = 0)

linkType Value

ospfLinkPointToPoint for unnumbered connections, the interface’s MIB-II ifIndex value

ospfLinkTransit the router interface’s IP address

ospfLinkStub the network’s IP address mask

ospfLink the router interface’s IP address

linkType Value

ospfLinkPointToPoint the neighboring router’s router ID

ospfLinkTransit the IP address of the Designated Router

ospfLinkStub the IP network/subnet number

ospfLink the neighboring router’s router ID

Option Value Usage

ospfLinkPointToPoint 1 a point-to-point connection to another router

ospfLinkTransit 2 (default) a connection to a transit network

ospfLinkStub 3 a connection a stub network

ospfLink 4 a virtual link


ospfRouterLsaInterface

COMMANDS The ospfRouterLsaInterface command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

ospfRouterLsaInterface cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfRouterLsaInterface command.

ospfRouterLsaInterface config option valueModify the configuration options of the ospfRouterLsaInterface. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfRouterLsaInterface.

ospfRouterLsaInterface setDefault



SEE ALSO ospfServer, ospfInterface, ospfRouter, ospfRouteRange, ospfUserLsaGroup, osp-fUserLsa


ospfServerA

NAME - ospfServerospfServer - access the OSPF component of the Protocol Server for a particular port.

SYNOPSIS ospfServer sub-command options

DESCRIPTION The ospfServer command is necessary in order to access the OSPF Protocol Server for a particular port. The select sub-command must be used before all other OSPF commands. Refer to “OSPF” on page 3-17 for a discussion on OSPF testing with Ixia equipment. Refer to “ospfServer” on page 5-58 for an overview.

STANDARD OPTIONS

None

COMMANDS The ospfServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ospfServer addRouter routerLocalIdAdds the OSPF router described in the ospfRouter command to the list of routers associated with the port. The router’s entry in the list is given an identifier of routerLocalId. Specific errors are:

• ospfServer select hasn’t been called• The router parameters in ospfRouter are invalid• A router with this routerLocalId exists already in the list

ospfServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfServer command.

ospfServer clearAllRouters

Deletes all the OSPF routers in the list. Specific errors are: • ospfServer select hasn’t been called

ospfServer config option valueModify the configuration options of the ospfServer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfServer.

ospfServer delRouter routerLocalIdDeletes the OSPF router described that has an identifier of routerLocalId. Spe-cific errors are:

• ospfServer select hasn’t been called• There is no router with this routerLocalId in the list


ospfServer

ospfServer generateStreams chasID cardID portID actionThis command creates additional streams for the indicated port and replaces the port’s current streams or adds it to the current streams depending on the action option:

A separate stream is generated for each enabled route range associated with each router; each stream covers the count of IP addresses associated with the route range. The characteristics of the generated streams are:


• Ethernet II encapsulation is used.• IPv4 framing is used.• The transmission rate is the port’s maximum rate.• Minimum frame sizes are used.• A data pattern of incrementing bytes (00 01 02 ...) is used.• The source MAC address is set from the value associated with the indicated

sending port.• The destination MAC address is set via an ARP lookup on the destination IP

address, which is set using UDF4.• A single burst of packets is sent per stream, with the count equal to the count of

addresses in the route range.• UDF4 or IP address controls are used to iterate through the count of addresses

in the route range; it should not be reprogrammed.

ospfServer getFirstRouter

Access the first OSPF router in the list. The results may be accessed using the ospfRouter command. Specific errors are:

• ospfServer select hasn’t been called• There are no routers in the list

ospfServer getNextRouter

Access the next OSPF router in the list. The results may be accessed using the ospfRouter command. Specific errors are:

• ospfServer select hasn’t been called• ospfServer getFirstRouter hasn’t been called• There are no more routers in the list

ospfServer getRouter routerLocalIdAccess the OSPF router with an identifier of routerLocalId. The results may be accessed using the ospfRouter command. Specific errors are:

• ospfServer select hasn’t been called• There is no router with this routerLocalId in the list

ospfServer select chasID cardID portIDAccesses the OSPF component of the Protocol server for the indicated port. Spe-cific errors are:

• No connection to the chassis• The OSPF protocol package has not been installed• Invalid port specified

Option Value Usage




ospfServerA

ospfServer setRouter routerLocalIdSets the values for the router’s entry in the list with an identifier of routerLocalId based on changes made through the ospfRouter command. This command should be used to change a running configuration and must be followed by an ospfServer write command in order to send these changes to the Protocol Server. Specific errors are:


ospfServer write

Sends any changes made with ospfRouter setInterface, ospfRouter setRouteRange, ospfRouter setUserLsaGroup or ospfServer setRouter to the Pro-tocol Server for immediate application. This command must be used after those mentioned above in order for their changes to have an effect.


# Define parameters used by OSPF routerset host rubyif [ixInitialize $host] { logMsg “Error in connecting to hostName” return 1}

# Port is card 9, port 1set ch [chassis cget -id]set ca 9set po 1set pl [list [list $ch $ca $po]]set myMac {00 0a de 01 01 01}set router 101.101.9.2set neighbor 101.101.9.1set interfaceIpMask 255.255.255.0set ospfInterfaceNetworkType ospfBroadcastset areaId 0set numberOfRoute 1650

# Set up IP address table for others who ARP to usipAddressTableItem setDefault ipAddressTableItem config -numAddresses 1ipAddressTableItem config -mappingOption oneIpToOneMACipAddressTableItem config -overrideDefaultGateway falseipAddressTableItem config -fromIpAddress $routeripAddressTableItem config -fromMacAddress $myMacipAddressTable addItemipAddressTable config -defaultGateway $neighboripAddressTable set $ch $ca $po

# Select port to operateospfServer select $ch $ca $po

# Clear all routers ospfServer clearAllRouters

# Configure the interfaceospfInterface setDefault ospfInterface config -enable trueospfInterface config -connectToDut trueospfInterface config -ipAddress $router


ospfServer

ospfInterface config -ipMask $interfaceIpMaskospfInterface config -areaId $areaIdospfInterface config -networkType ospfBroadcastospfInterface config -metric 10

# Add the ospf interface to the routerif [ospfRouter addInterface interface1] { logMsg “Error in adding ospfInterface interface1”}

# Configure the routeRangeospfRouteRange setDefault ospfRouteRange config -enable trueospfRouteRange config -metric 1ospfRouteRange config -numberOfNetworks $numberOfRouteospfRouteRange config -prefix 24ospfRouteRange config -networkIpAddress {14.0.0.0}

# Add the ospf routeRange to the routerif [ospfRouter addRouteRange routeRange1] { logMsg “Error in adding routeRange”}

# Configure ospf routerospfRouter setDefault ospfRouter config -routerId $ca.$po.0.0ospfRouter config -enable true

# Add the router to the serverif [ospfServer addRouter router1] { logMsg “Error in adding router”}

# Let the protocol server respond to ARP, OSPF and PINGprotocolServer config -enableArpResponse trueprotocolServer config -enableOspfService trueprotocolServer config -enablePingResponse falseprotocolServer set $ch $ca $po


# And start ospf on the portixStartOspf pl

# Disable routeRange1 while ospf server is runnung. # This is the same as removing the route range from router

ospfServer select $ch $ca $po

if [ospfServer getRouter router1] { logMsg “Error getting router1”}if [ospfRouter getRouteRange routeRange1] { logMsg “Error getting routeRange1”}

# Disable the route range (You can also change other configuration if you want)ospfRouteRange config -enable false

if [ospfRouter setRouteRange routeRange1] {logMsg “Error setting routeRange1”


ospfServerA

}if [ospfServer write] {

logMsg “Error writing ospfServer”}

after 10000#Stop the server at the endixStopOspf pl

# If you wanted to add a route range while ospf server is running, # -Configure it disabled before starting ospf server and then# enable it# The same thing is also possible on ospfInterface, ospfUserLsaGroup # and ospfUserLsa.# You just need to get the item that you want and change the configuration # and set that item. Then write the changes to hardware by ospfServer write

SEE ALSO ospfInterface, ospfRouter, ospfRouteRange, ospfUserLsaGroup, ospfUserLsa, ospfRouterLsaInterface


ospfUserLsa

NAME - ospfUserLsaospfUserLsa - configure an individual User LSA for use in OSPF.

SYNOPSIS ospfUserLsa sub-command options

DESCRIPTION The ospfUserLSA describes an individual LSA. The types supported are:• Route LSA – describes router’s interfaces with state and cost. This

consists of a list of ospfRouterLSAInterface elements added via the ospfUserLSA addInterfaceDescriptionToRouterLsa.

• Network LSA – generated by a designated router and lists all attached routers.

• Summary IP LSA – describes destinations outside of an area.• Summary ASBR LSA – generated by AS Border Routers and list

the ASBR itself.• Opaque LSA – used to carry information for other protocols and

functions, notably OSPF.Refer to “OSPF” on page 3-17 for a discussion on OSPF testing with Ixia equip-ment. Refer to “ospfUserLSA” on page 5-64 for an overview of this command.

STANDARD OPTIONS Each of the supported LSA types has a different set of applicable standard options. The common options and the LSA specific options are described in the multiple tables below. All values must be expressed as integers (not hex values, for example). The LSA type is described when the LSA is added to the group using “ospfUserLsaGroup” on page A-176.

Common

advertisingRouterId The router ID of the router that is originating the LSA. (default = 0.0.0.0)

age Read only. Only available when this command is used to access a learned LSA (see ospfInterface). This value holds the age of the LSA extracted from the LSA header.

enable true / false Indicates whether the LSA is to be used in the simulation. (default = false)

options Multiple options may be or’d together. The available options are:

Option Value Usage

0 (default)

ospfOptionBitTypeOfService 0x01

ospfOptionBitExternalRouting 0x02

ospfOptionBitMulticast 0x04

ospfOptionBitNSSACapability 0x08

ospfOptionBitExternalAttributes 0x10

ospfOptionBitDemandCircuit 0x20

ospfOptionBitLSANoForward 0x40


ospfUserLsaA

sequenceNumber Read only. Only available when this command is used to access a learned LSA (see ospfInterface). This value holds the sequence number of the LSA extracted from the LSA header.

Router LSA

linkStateId The router ID of the originating router. (default = 0.0.0.0)

routerCapabilityBits The router’s capability bits. Multiple bits are defined; to set more than one bit use the Tcl or ‘|’ operator. (default = 0). The bits defined are:

Network LSA

linkStateId The IP address of the network’s Designated Router. (default = 0.0.0.0)

neighborId A list of router IDs in the area, in IP address format separated by spaces. (default = { })

Summary IP LSA

incrementLinkStateIdBy

If numberOfLSAs > 1, the value to increment the linkStateId by for each LSA.IP format. (default = 0.0.0.0)

linkStateId The IP address of the network. (default = 0.0.0.0)

metric The cost of the route for all TOS levels. (default = 0)

networkMask The destination network’s IP address mask. (default = 0.0.0.0)

numberOfLSAs The number of Summary IP LSAs to generate. (default = 0)

Summary ASBR LSA

linkStateId The router ID of the AS Boundary router. (default = 0.0.0.0)

External LSA

externalMetricEbit The value of the external metric’s E-bit. (default = 0)

externalRouteTag The type of external metric. A value of 1 implies type 2 metric, in which case the metric value is larger than any internal metric. A value of 0 implies type 1 metrics, in which case the metric value is expressed in the same units as internal metrics. (default = 0.0.0.0)

ospfOptionBitUnused 0x80

Option Value Usage

Option Value Usage

ospfBBit 1 B bit

ospfEBit 2 E bit

ospfVBit 4 V bit


ospfUserLsa

forwardingAddress Data traffic for the advertised destination will be forwarded to this address. If set to 0.0.0.0, then traffic will be forwarded to the AS boundary router itself. (default = 0.0.0.0)

incrementLinkStateIdBy

If numberOfLSAs > 1, the value to increment the linkStateId by for each LSA.IP format. (default = 0.0.0.0)

linkStateId The IP network number of the external destination. 0.0.0.0 is used to indicate a default route. (default = 0.0.0.0)

metric The cost of the route, applied to all TOS values. (default = 0)

networkMask The IP address mask for the advertised destination. 0.0.0.0 is used to indicate a default route. (default = 0.0.0.0)

numberOfLSAs The number of External LSAs to generate. (default = 0)

Opaque Local, Opaque Area and Opaque Domain LSAs

linkStateId The high-order 8 bits indicate the Opaque type as defined in RFC 2370. The low-order 24 bits indicate the type-specific ID. (default = 0.0.0.0)

tlvType Indicates the type of TLV (type-length-value) to be generated. This should be set to one of:

For Router TLVs

tlvRouterIpAddress The stable IP address of the advertising router that is always reachable if there is any connectivity to it. This is typically implemented as a “loopback address”. (default = 0.0.0.0)

For Link TLVs

enableTlvLinkId true / false

Enables the generation of a sub-TLV for the Link ID, based on the value of the tlvLinkId. (default = 0)

enableTlvLinkMetrictrue / false

Enables the generation of a sub-TLV for the Link Metric, based on the value of the tlvLinkMetric. (default = 0)

enableTlvLinkTypetrue / false

Enables the generation of a sub-TLV for the Link Type, based on the value of the tlvLinkType. (default = 0)

enableTlvLocalIpAddress true / false

Enables the generation of a sub-TLV for the Local IP address, based on the value of the tlvLocalIpAddress. (default = 0)

enableTlvMaxBandwidth true / false

Enables the generation of a sub-TLV for the Max Bandwidth, based on the value of the tlvMaxBandwidth. (default = 0)

Option Value Usage

ospfRouterTlv 0 (default)

ospfLinkTlv 1


ospfUserLsaA

enabletlvMaxReservableBandwidthtrue / false

Enables the generation of a sub-TLV for the Max Reservable Bandwidth, based on the value of the tlvMaxReservableBandwidth. (default = 0)

enableTlvRemoteIpAddress true / false

Enables the generation of a sub-TLV for the Remote IP Address, based on the value of the tlvRemoteIpAddress. (default = 0)

enableTlvResourceClass true / false

Enables the generation of a sub-TLV for the Resrouce Class, based on the value of the tlvResourceClass. (default = 0)

enableTlvUnreservedBandwidth true / false

Enables the generation of a sub-TLV for the Unreserved Bandwidth, based on the value of the tlvUnreservedBandwidthPriority0-7. (default = 0)

tlvLinkId Identifies the other end of the link. For point-to-point links, thie is the ROuter ID of the neighbor. For multiaccess link, sthis is the interface address of the designated router. (default = 0.0.0.0)

tlvLinkMetric The link metric for traffic engineering purposes. (default = 0)

tlvLinkType The type of the link, one of:

tlvLocalIpAddress The IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this Tlv. (default = 0.0.0.0)

tlvMaxBandwidth The maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor). This is the true link capasity expressed in bytes per second. (default = 0)

tlvMaxReservableBandwidth

The maximum bandwidth that may be reserved on this link in this direction, (from the system originating the LSA to its neighbor). Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). Units are in bytes per second. (default = 0)

tlvRemoteIpAddress The IP address(es) of theneighbor’s interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. (default = 0.0.0.0)

tlvResourceClass Specifies the administrative group membership for this link, in terms of a bit mask. A link that is a member of multiple groups will have multiple bits sent. (default = 00 00 00 00)

tlvUnreservedBandwidthPriority0-7

The amount of bandwidth not yet reserved, at each of eight priority levels. Each value must be less than or equal to the maximum reservable bandwidth. Units are in bytes per second. (default = 0.0)

COMMANDS The ospfUserLsa command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

Option Value Usage

ospfTlvLinkPointToPoint 1 (default)

ospfTlvLinkBroadcast 2


ospfUserLsa

ospfUserLsa addInterfaceDescriptionToRouterLsa

This command is for use with Router Interface LSAs only. Adds the router inter-face LSA described in the ospfRouterLsaInterface command to the list. Specific errors are:

• The parameters in ospfRouterLsaInterface are invalid

ospfUserLsa cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfUserLsa command.

ospfUserLsa clearAllRouterLsaInterface

This command is for use with Router Interface LSAs only. Deletes all of the user Router Interface LSAs.

ospfUserLsa config option valueModify the configuration options of the ospfUserLsa. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfUserLsa.

ospfUserLsa getFirstRouterLsaInterface

This command is for use with Router Interface LSAs only. It accesses the first Router Interface LSA entry in the list. The user LSA is accessed in the osp-fRouterLsaInterface command. Specific errors are:

• The type of this ospfUserLsa entry is not ospfLsaRouter• There are no items in the list.

ospfUserLsa getNextRouterLsaInterface

This command is for use with Router Interface LSAs only. It accesses the next Router Interface LSA entry in the list. getFirstRouterLsaInterface must be called before any calls to this command. The user LSA is accessed in the osp-fRouterLsaInterface command. Specific errors are:

• There are no more items in the list.

ospfUserLsa setDefault



SEE ALSO ospfServer, ospfInterface, ospfRouter, ospfRouteRange, ospfUserLsaGroup, osp-fRouterLsaInterface


ospfUserLsaGroupA

NAME - ospfUserLsaGroupospfUserLsaGroup - configure a User LSA group for use in OSPF.

SYNOPSIS ospfUserLsaGroup sub-command options

DESCRIPTION The ospfUserLSAGroup describes a list of LSAs to be associated with advertised routes. The list consists of elements constructed through the use of the ospfU-serLsa command. Refer to “OSPF” on page 3-17 for a discussion on OSPF test-ing with Ixia equipment. Refer to “ospfUserLSAGroup” on page 5-64 for an overview of this command.

STANDARD OPTIONS

areaId The area ID for the LSA group. (default = 0)

description A commentary description for the user LSA group. (default = ““)

enable true / false Enables the use of this router in the simulated OSPF network. (default = fasle)

COMMANDS The ospfUserLsaGroup command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

ospfUserLsaGroup addUserLsa userLsaLocalId lsaTypeAdds the user LSA described in the ospfUserLsa command and of type lsaType to the list. The LSA’s entry in the list is given an identifier of userLsaLocalId. The choices of lsaType are:

Specific errors are: • The LSA type in ospfUserLsa is not valid• The parameters in ospfUserLsa are invalid• A router with this userLsaLocalId exists already in the list

ospfUserLsaGroup cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ospfUserLsaGroup command.

Option Value Usage

ospfLsaRouter 1

ospfLsaNetwork 2

ospfLsaSummaryIp 3

ospfLsaSummaryAs 4

ospfLsaExternal 5

ospfLsaOpaqueLocal 9

ospfLsaOpaqueArea 10

ospfLsaOpaqueDomain 11


ospfUserLsaGroup

ospfUserLsaGroup clearAllUserLsas

Deletes all of the user LSAs.

ospfUserLsaGroup config option valueModify the configuration options of the ospfUserLsaGroup. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for ospfUserLsaGroup.

ospfUserLsaGroup delUserLsa userLsaLocalIdDeletes the user LSA with an identifier of userLsaLocalId. Specific errors are:

• No LSA with this userLsaLocalId exists in the list

ospfUserLsaGroup getFirstUserLsa

Access the first user LSA in the list. The results may be accessed using the osp-fUserLsa command. Specific errors are:

• There are no routers in the list

ospfUserLsaGroup getNextUserLsa

Access the next user LSA in the list. The results may be accessed using the osp-fUserLsa command. Specific errors are:

• ospfUserLsaGroup getFirstUserLsa hasn’t been called• There is no more LSAs in the list

ospfUserLsaGroup getUserLsa userLsaLocalIdAccesses the LSA’s entry in the list with an identifier of userLsaLocalId. The user LSA is accessed in the ospfUserLsa command. Specific errors are:

• No LSA with this userLsaLocalId exists in the list

ospfUserLsaGroup setDefault


ospfUserLsaGroup setInterface userLsaLocalIdSets the values for the user LSA’s entry in the list with an identifier of userLsaLocalId based on changes made through the ospfUserLsa command. This command can be used to change a running configuration and must be followed by an ospfServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A user LSA with this ospfUserLsa does not exist in the list


SEE ALSO ospfServer, ospfInterface, ospfRouter, ospfRouteRange, ospfUserLsa, osp-fRouterLsaInterface


packetGroupA

NAME - packetGrouppacketGroup - configure the Packet Group parameters.

SYNOPSIS packetGroup sub-command options

DESCRIPTION The packetGroup command is used to configure the parameters for Packet Groups. Packet groups are given unique IDs within which metrics such as mini-mum, maximum and average latency for every incoming frame is calculated by the hardware in real-time.

STANDARD OPTIONS

allocateUdf true / false Assigns one of the User-Defined Fields for use with the Sequence Number. (default = true)

groupId Unique value used to identify one packet group for another. Up to 57344 different packet groups may be defined. (default = 0)

groupIdOffset The offset, within the packet, of the group id value. (default = 52)

ignoreSignature true / false

In receive mode, the signature field is not matched and all packets are counted. (default = false)

insertSequenceSignature true / false

Inserts a sequence signature into the packet as indicated by signatureOffset, signatureValue, groupIdOffset, signatureNumberOffset and allocateUdf. (default = false)

insertSignature true|false

Inserts the packet group signature into the transmitted stream. (default = false) Note: For calculating latency values need to configure stream config –fir true.

latencyControl Defines the mechanism used to calculate latency. Possible values include:

preambleSize Length of preamble, in bytes, of received frame. (default = 8)

sequenceNumberOffset The offset within the packet of the sequnce number. This is valid only when sequence checking is enabled. (default = 44)

signature In the transmitted packet, the signature uniquely signs the transmitted packet as one destined for packet group filtering on the receive port. On the receive port, the signature is used to filter only those packets that have a matching signature and the minimum, maximum and average latencies are obtained for those packets. (default = 08 71 18 05)

signatureOffset The offset, within the packet, of the packet group signature. (default = 46)

Option Value Usage

cutThrough 0x01 (default) first data bit in to first data bit out

storeAndForward 0x03 last data bit in to first data bit out

storeAndForwardPreamble 0x05 last data bit in to first preamble out


packetGroup

COMMANDS The packetGroup command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

packetGroup cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the packetGroup command.

packetGroup config option valueModify the Packet Group configuration options of the port. If no option is speci-fied, returns a list describing all of the available Packet Group options (see STANDARD OPTIONS) for port.

packetGroup getRx chasID cardID portIDGets the current receive Packet Group configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling packetGroup cget option value to get the value of the configuration option. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user

packetGroup getTx chasID cardID portID streamIDGets the current transmit Packet Group configuration of the stream with id portID on card cardID, chassis chasID, stream streamID. Call this command before calling packetGroup cget option value to get the value of the configura-tion option. specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• No stream has been configured for the streamID

packetGroup setDefault


packetGroup setRx chasID cardID portIDSets the receive Packet Group configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the packetGroup config option value command. Specific errors are:


packetGroup setTx chasID cardID portID streamIDSets the transmit Packet Group configuration of the stream with id portID on card cardID, chassis chasID, stream streamID by reading the configuration option values set by the packetGroup config option value command. After call-ing this command, the Packet Group configuration should be committed to hard-ware using stream write or ixWriteConfigToHardware commands. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• No stream has been configured for the streamID


packetGroupA


# In this example, we’ll measure the latency for different frame sizes through# a simple switch using packet groups.

# Port 1 is used to transmit three streams, each with a packet group signature# and packet group ID equal to the stream ID. 100,000 packets are transmitted# by each stream

# Port 2 is used to received the data using Packet Group Mode.# A short stream is transmitted from this port to the switch in order to# get the switch to ‘learn’ its MAC address


# Assumes that card 1 is a 10/100 card with both ports connected to # a simple L2 switchset card 1set txPort 1set rxPort 2


# Test parameters# Port 1’s MAC addressset p1MAC [list 00 00 00 01 01 01]# Port 2’s MAC addressset p2MAC [list 00 00 00 01 01 02]# Number of frames to transmitset numFrames 100000

# Frame sizesset fs(1) 64set fs(2) 1024set fs(3) 1518set numFrameSizes 3


port setFactoryDefaults $chas $card $txPort

# stream: from port 1 MAC to port 2 MAC, stream size as per array# Make sure to insert time stamp (fir)set streamID 1stream setDefaultstream config -numFrames $numFramesstream config -sa $p1MACstream config -da $p2MACstream config -fir truestream config -dma advancestream config -framesize $fs($streamID)stream config -enableIbg false


packetGroup

stream config -enableIsg falsestream set $chas $card $txPort $streamID

# Make sure to insert a PG signature and streamID = PGIDpacketGroup setDefaultpacketGroup config -insertSignature truepacketGroup config -groupId truepacketGroup setTx $chas $card $txPort $streamID

# The same thing for stream 2, but with different framesizeset streamID 2stream config -framesize $fs($streamID)stream set $chas $card $txPort $streamIDpacketGroup setTx $chas $card $txPort $streamID

# The same thing for stream 3, but with different framesize# and stop after this stream is doneset streamID 3stream config -framesize $fs($streamID)stream config -dma stopStreamstream set $chas $card $txPort $streamIDpacketGroup setTx $chas $card $txPort $streamID

# Set up Receive Port

port setFactoryDefaults $chas $card $rxPort

# Set up receive packet group mode (store and forward)packetGroup setDefaultpacketGroup config -latencyControl storeAndForwardpacketGroup setRx $chas $card $rxPort

# and the port must be in packet group modeport config -receiveMode portPacketGroupport set $chas $card $rxPort

# Set up a short burst with correct MAC addr in order to get the# switch to learn the MAC address for the receive portstream setDefaultstream config -numFrames 10stream config -sa $p2MACstream config -da $p1MACstream config -dma stopStreamstream set $chas $card $rxPort 1

# Let the hardware know about the two portsixWritePortsToHardware portList

# Wait for changes to take affect and make sure links are upafter 1000ixCheckLinkState portList

# Send the learning frames to the switchixStartPortTransmit $chas $card $rxPortafter 1000ixCheckPortTransmitDone $chas $card $rxPort

# Now for the main event - start the packet groups on the receive port# and then the transmit from the transmit portixStartPortPacketGroups $chas $card $rxPortixStartPortTransmit $chas $card $txPortafter 1000


packetGroupA

# and then wait for things to be doneixCheckPortTransmitDone $chas $card $txPortixStopPortPacketGroups $chas $card $rxPort

# Now get the statistics back# First a get for all of the packet groupspacketGroupStats get $chas $card $rxPort 1 $numFrameSizesixPuts “FrameSz\tMinLat\tAvgLat\tMaxLat”ixPuts “-------\t-------\t-------\t-------”

# Then each individually to get the statisticsfor {set i 1} {$i <= 3} {incr i} \{ packetGroupStats getGroup $i ixPuts -nonewline “$fs($i)\t” ixPuts -nonewline [packetGroupStats cget -minLatency] ixPuts -nonewline “\t” ixPuts -nonewline [packetGroupStats cget -averageLatency] ixPuts -nonewline “\t” ixPuts [packetGroupStats cget -maxLatency]}

SEE ALSO packetGroupStats


packetGroupStats

NAME - packetGroupStatspacketGroupStats - retrieve that stats associated with a packet group.

SYNOPSIS packetGroupStats sub-command options

DESCRIPTION The packetGroupStats command is used to retrieve the stats associated with packet groups, such as minimum latency, maximum latency and average latency.

STANDARD OPTIONS

averageLatency Read-only. 64-bit value. Average latency for all frames of this packet group. Updated after packetGroupStats getGroup command is called.

bitRate Read-only. 64-bit value. The bit rate for the frames. Note: this value is calculated on the difference between two successive readings; packetGroupStats get must be called at least twice before valid values are obtained.

firstTimeStamp Read-only. 64-bit value. Transmit start time stamp.

lastTimeStamp Read-only. 64-bit value. Transmition stop time stamp.

maxLatency Read-only. 64-bit value. Maximum latency of all frames of this packet group. Updated after packetGroupStats getGroup command is called.

minLatency Read-only. 64-bit value. Minimum latency of all frames of this packet group. Updated after packetGroupStats getGroup command is called.

numGroups Read-only. The total number of groups that were actually received.

totalFrames Read-only. 64-bit value. Total number of frames used to calculate the statistics for this packet group.

COMMANDS The packetGroupStats command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

packetGroupStats cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the packetGroupStats command.

packetGroupStats get chasID cardID portID fromGroupID toGroupIDGets the current Packet Group statistics on the port with id portID on card car-dID, chassis chasID. Call this command before calling packetGroupStats getGroup groupId and packetGroupStats cget option value to get the value of the configuration option. fromGroupID and toGroupID are optional. Specific errors are:

• No connection to a chassis• Invalid port number• The fromGroupID or toGroupID is invalid


packetGroupStatsA

• Network error between the client and the chassis• Either group ID is outside the range 0 through 57343

packetGroupStats getGroup groupIDGets the Packet Group statistics for this groupID. Before calling this command, packet group statistics must be retrieved using the packetGroupStats get chasID cardID portID command. Call this command before calling packetGroupStats cget option value to get the value of the configuration option. Specific errors are:

• No packet groups are defined• The groupIndex packet group does not exist• Either group ID is outside the range 0 through 57343

packetGroupStats setDefault

Zeros all local stats in the packet group stat list.

EXAMPLES See examples under portGroup.

SEE ALSO portGroup, stream


port

NAME - portport - configure a port of a card on a chassis.

SYNOPSIS port sub-command options

DESCRIPTION The port command is used to configure the properties of a port of a card on a chassis.

STANDARD OPTIONS

advertise1000FullDuplex true/false

If set to true, this port will advertise itself at 1000 Mbps and Full duplex mode (applicable to gigabit ports only). (default = false)


If set to true, this port will advertise itself at 100 Mbps and Full duplex mode (applicable to 10/100 port only). (default = true)

advertise100HalfDuplex true/false

If set to true, this port will advertise itself at 100 Mbps and Half duplex mode (applicable to 10/100 port only). (default = true)


If set to true, this port will advertise itself at 10 Mbps and Full duplex mode (applicable to 10/100 port only). (default = true)

advertise10HalfDuplex true/false

If set to true, this port will advertise itself at 10 Mbps and Half duplex mode (applicable to 10/100 port only). (default = true)

advertiseAbilities Sets up the auto-negotiation parameters for gigabit (applicable to Gigabit only). The value of flowControl must be true for this field to have an effect. The options are:

autonegotiate true/false

Sets/unsets auto-negotiate mode on a 10/100 port. (default = false)

DestMacAddress The MAC address of the DUT port to which the Ixia source port is connected. Used for running IP tests. Entered in form {01 02 03 04 05 06}. (default = 00 de bb 00 00 00)

NOTE: This value is not written in HAL or hardware. It is merely stored in TclHal so that it can be accessed at any time. The MAC addresses should be set with the stream command.

Option Value Usage

portAdvertiseNone 0 (default) Do not advertise flow control abili-ties

portAdvertiseSend 1 Send only (asymmetric to link partner)

portAdvertiseSendAndReceive 2 Send and receive (symmetric to link part-ner)

portAdvertiseSendAndOrReceive 3 Send and/or receive (both symmetric or asymmetric to link partner)


portA

directedAddress This is the address that port will listen on for a directed pause message. (default = 01 80 C2 00 00 01)

duplex half/full Set the duplex mode to half duplex or full duplex on a 10/100 port. (applicable to 10/100 only) (default = full)

enableManualAutoNegotiate true/false

If set to true, then as the port configuration is written to hardware auto negotiation will begin. (applicable to MII only) (default = false)

enablePhyPolling true/false

If set to true, the PHY will be continuously polled during Mii setup operation. (default = true)

flowControl true/false Sets/unsets flow control on a port. (default = false)

gigVersion Read-only. FPGA version of the gigabit port. (applicable to Gigabit only)

ignoreLink true/false Ignores the link on Gigabit port if set to true. (applicable to Gigabit only) (default = false)

linkState Read-only. The following states can be read from the port:

Option Value Usage

linkDown 0 The link on the port is down. This may be because there is no cable connected to the port or the link on the destination port may be down. The LED on the card is off when the link is down.

linkUp 1 the link is up indicated by green LED on the card.

linkLoopback 2 the port has been set to loopback mode. The LED on the card is off in this mode.

miiWrite 3 the link is in this state when the configuration of 10/100 port is being written to hardware (applicable to 10/100 only)

restartAuto 4 restarts the auto-negotiation process

autoNegotiating 5 the link is in currently executing the auto-negotiation process

miiFail 6 failed to write into memory for 10/100 ports (applica-ble to 10/100 only)

noTransceiver 7 No external transceiver detected on Ixia Mii or Rmii port.

invalidAddress 8 No PHY detected at the selected address.

readLinkPartner 9 Auto negotiation state in negotiation process. This is an intermediate state and should be used for infor-mational purposes only.

noLinkPartner 10 Auto negotiation state in negotiation process. No link partner was found. This is an intermediate state and should be used for informational purposes only

restartAutoEnd 11 Auto negotiation state in negotiation process. This is an intermediate state and should be used for infor-mational purposes only.

fpgaDownloadFail 12 Fpga download failure. Port will not be usable.

noGbicModule 13 No GBIC module detected on Ixia Gbic port.

fifoReset 14 State in board initialization process. This is an inter-mediate state used for informational purposes only.


port

fifoResetComplete 15 State in board initialization process. This is an inter-mediate state and used for informational purposes only.

pppOff 16 PPP is disabled. PPP control packets will be ignored; PPP link negotiation will not be performed. Does not mean the link is unusable; it may, for instance, be configured for Cisco/HDLC and traffic (non-PPP) may still flow.

pppUp 17 The fully operational state when PPP is enabled. PPP link negotiation has successfully completed and the link is available for normal data traffic.

pppDown 18 The non-operational state when PPP is enabled. PPP link negotiation has failed or the link has been administratively disabled.

pppInit 19 PPP link negotiation state. This is an intermediate state and should be used for informational purposes only. Initialization state at the start of the negotiation process.

pppWaitForOpen 20 PPP link negotiation state: Waiting for indication from PPP controller that auto negotiation and related PPP control packet transfers can proceed. This is an inter-mediate state and should be used for informational purposes only.

pppAutoNegotiate 21 PPP link negotiation state: In process of exchanging PPP control packets (e.g., LCP and IPCP) to negoti-ate link parameters. This is an intermediate state and should be used for informational purposes only.

pppClose 22 PPP link negotiation state: The PPP session has been terminated. All data traffic will stop.

pppConnect 23 PPP link negotiation state: Negotiation has success-fully completed; the peers are logically connected. Normal data traffic may flow once the pppUp state is reached. This is an intermediate state and should be used for informational purposes only.

lossOfFrame 24 Physical link is down. (e.g., loss of signal, loss of frame)

lossOfSignal 25 Physical link is down. (e.g., loss of signal, loss of frame)

lossOfFramePppDisabled

26 PPP link negotiation state: Physical link has gone down and PPP negotiation has been stopped.

stateMachineFailure 27 Communication with the local processor has failed. Check Server display and log for possible failure.

pppRestartNegotiation 28 PPP link negotiation state, following explicit request to restart negotiation process: this state indicates response to request.This is an intermediate state and should be used for informational purposes only.

pppRestartInit 29 PPP link negotiation state, following explicit request to restart negotiation process: the link has or will be brought down in order to begin a new negotiation cycle. This is an intermediate state and should be used for informational purposes only.

Option Value Usage


portA

loopback true/false Sets/unsets loopback mode on a port. (default = false)

MacAddress Assigns a Source MAC address to the port. MAC address is entered in form {01 02 03 04 05 06}. (default = 00 de bb 00 01 01)

NOTE: This value is not written in HAL or hardware. It is merely stored in TclHal so that it can be accessed at any time. The MAC addresses should be set with the stream command.

masterSlave Only apply to GIG MII. If negotiateMsterSlave is ‘false’, then the masterSlave is essentially read-only. Options include:

multicastPauseAddress This is the address that the port will listen on for a multicast pause message. (default = 01 80 C2 00 00 01)

name The given name of the port. (default = “”)

negotiateMasterSlave true/false

Only apply to Gigabit MII. Enable negotiateMasterSlave. (default = false)

numAddresses Number of source MAC addresses assigned to this port. (default = 1)

NOTE: This value is not written in HAL or hardware. It is merely stored in TclHal so that it can be accessed at any time.

pppRestartWaitForOpen

30 PPP link negotiation state, following explicit request to restart negotiation process: Waiting for indication from PPP controller that current connection is already down or is in process of being shut down. This is an intermediate state and should be used for informational purposes only.

pppRestartWaitForClose

31 PPP link negotiation state, following explicit request to restart negotiation process: Waiting for indication from PPP controller that shut down of current con-nection has completed.This is an intermediate state and should be used for informational purposes only.

pppRestartFinish 32 PPP link negotiation state, following explicit request to restart negotiation process: Preparation for restart completed; ready to begin normal cycle again. This is an intermediate state and should be used for infor-mational purposes only.

localProcessorDown 33 local processor boot failure

forceLinkUp 34 Link has been forced up.

temperatureAlarm 35 An over-temperature condition has occurred.

pppClosing 36 PPP negotiation is closing.

pppLcpNegotiate 37 PPP LCP negotiation in process.

pppAuthenticate 38 PPP authentication in process.

pppNcpNegotiate 39 PPP NCP negotiation in process.

demoMode 40 Server is in demo mode.

Option Value Usage

Option Value Usage

portMaster 0

portSlave 1 (default)


port

owner Read-only. Name of the owner of this port, if any. (default = “”)

packetFlowFileName Sets the packet flow file name. To set the packet flow file name, need to enable usePacketFlowImage File first. (default = “”)

portMode If the card on which the port appears is a USB/Ethernet type card, then this indicates the curent mode of the port. (default = 0) One of:

If the card on which the port appears is a OC192/10Gig type card, then this indicates the current mode of the the port. One of:

Note that port setFactoryDefault will not reset the port mode associated with OC192/10Gig type cards.

rateMode The rate may be entered in one of the following modes. NOTE: This value is not written in HAL or hardware. It is merely stored in TclHal so that it can be accessed at any time.

receiveMode Sets up the type of capture/receive mode for this port. NOTE: The receive modes are and’d and or’d to determine which fpga is required for what interface. Options include:

rxFpgaVersion Read-only. FPGA version of the receive engine of the 10/100 port. (applicable to 10/100 only)

Option Value Usage

portEthernetFraming 1 indicates Ethernet mode on the port.

portUsbEthernet 20 indicates USB mode on the port.

Option Value Usage

portPosFraming 0 indicates OC192 POS operation on the port.

portEthernetFraming 1 indicates 10Gig Ethernet operation on the port.

Option Value Usage

useGap 0 (default) the rate is entered in clock ticks used to cal-culate the inter-frame gap

usePercentRate 1 the rate is entered as a percentage of maximum rate

Option Value Usage

portCapture 1 (default) use normal capture buffer

portPacketGroup 2 get real time latency on received packets

portRxTcpSessions 4 use TCP session

portRxTcpRoundTrip 8 do TCP Round trip

portRxDataIntegrity 16 do data integrity

portRxFirstTimeStamp 32 get the first receive time

portRxSequenceChecking 64 do sequence checking

portRxModeBert 128 Bit Error Rate testing mode


portA

rxTxMode Sets one of following modes on a Gigabit port

speed 10|100 Set the line speed to 10 Mbps or 100 Mbps on a 10/100 port. Speed cannot be set on a Gigabit port. (default =100)

timeoutEnabletrue / false

Enables the gigabit auto-negotiation timeout. (applicable to Gigabit only) (default = true)

transmitMode Sets the type of stream/transmit mode for this port. Options include:

txFpgaVersion Read-only. FPGA version of the transmit engine of the 10/100 port. (applicable to 10/100 only)

type Read-only. Specifies the type of the Ixia port. Valid port types include:

Option Value Usage

gigNormal 0 (default) The Gigabit port runs as full duplex.

gigLoopback 1 The Gigabit port transmits and receives frames in internal loopback.

gigCableDisconnect 2 simulate cable disconnect on the port

Option Value Usage

portTxPacketStreams 0 (default) set up hardware to use normal streams

portTxPacketFlows 1 set up hardware to use packet flows

portTxModeAdvancedScheduler 4 set up hardware to use the advanced scheduler

portTxModeBert 5 set up the hardware to use Bit Error Rate patterns

Option Value Usage

port10100BaseTX 1

port10100BaseMII 2

port100BaseFXMultiMode 3

port100BaseFXSingleMode 4

portGigabitSXMultiMode 5

portGigabitLXSingleMode 6

portReducedMII 7

portGbic 8

portPacketOverSonet 9

port10100Level3 10

portGigabitLevel3 11

portGbicLevel3 12

portGigCopper 13

portPosOc48 14

portPosOc48Level3 15

portPosOc192 16

portPosOc192Level3 17

portUsbUsb 18


port

typeName Read only. The name equivalent of the type field.

usePacketFlowImageFile enable/disable

Enable the Packet Flow Image File. (default = disable)


useRecoveredClock true/false

Set the sonet framer to use the recovered clock. (applicable to POS/sonet only) (default =false)

COMMANDS The port command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

port canUse chasID cardID portIDIf the port is owned by the current logged in user, canUse will return true, other-wise it will return false. Specific errors are:


portGigaCopperGMii 19

portUsbEthernet 20

portPosOc192Fob2 21

portPosOc192Fob1 22

portPosOc192Plm2 23

portPosOc192Plm1 24

portPosOc3 26

portPosOc48VariableClocking 27

portGigCopperTripleSpeed 28

portGigSingleMode 29

portOc48Bert 32

portOc48PosAndBert 33

port10GigWanPlm2 36

port10GigWanPlm1 37

port10GigLanXgmiiPlm1 41

port10GigLanXuaiPlm1 45

port10GigLanXsbiPlm1 53

port10100UsbSh4 55

port10100Sh4 57

portLffCarrier1 60

portLffCarrier1 61

portLff10100Dpm 62

port10100Dpm 63

Option Value Usage


portA

port cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the port command.

port config option valueModify the configuration options of the port. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for port.

port export fileName chasID cardID portIDExports the current configuration of the port at portID, cardID, chasID into the file named fileName. The file produced by this command may be used by the import sub-command. Specific errors are:

• No connection to a chassis• Invalid port

port get chasID cardID portIDGets the current configuration of the port with id portID on card cardID, chassis chasID from its hardware. Call this command before calling port cget option value to get the value of the configuration option. Specific errors are:


port getId chasID cardID portIDGets the name of the port as a string of format <chassis>.<card>.<port> <port-name> or <chassis>.<card>.<port> if the port has no name. For example, 1.2.3 router1.

port getInterface chasID cardID portIDGets the interface type of the port. This command returns one of the following values:

port import fileName chasID cardID portIDImports a saved port configuration found in the file fileName into the current configuration of the port at portID, cardID, chassis chasID. The file used by this command must have been produced by the export sub-command. A port write is necessary to commit these items to the hardware. Specific errors are:

• No connection to a chassis• Invalid port• The card is owned by another user

Option Value Usage

interfaceUnknown 0

interface10100 1

interfaceGigabit 2

interfacePacketOverSonet 3 for OC3 and OC12

interfaceOc48 4

interfaceOc192 5

interfaceUSB 6

interface10100Gigabit 7


port

• fileName does not exist

port isActiveFeature chasID cardID portID featureDetermines whether a specific feature is available for the port at portID, cardID, chassis chasID and that the port is properly configured to use that feature. A value of true (1) is returned if the feature is active and false (0) if the feature is in active or the port is invalid. Feature may be one of the following values:

port isValidFeature chasID cardID portID featureDetermines whether a specific feature is available for the port at portID, cardID, chassis chasID. A value of true (1) is returned if the feature is valid and false (0) if the feature is in valid or the port is invalid. Feature may be one of the follow-ing values:

portFeatureRxPacketGroups 3 supports packet group mode as described in “Packet Group Operation” on page 3-11.

portFeatureRxDataIntegrity 5 supports received data integrity checking as described in “Data Integrity Checking Oper-ation” on page 3-13.

portFeatureRxRoundTripFlows 6 supports receive round trip flow mode as described in “Round Trip TCP Flows” on page 3-14.

portFeaturePos 13 supports packet over sonet operation as described in “PPP Protocol Negotiation” on page 3-32.

portFeatureBert 14 supports bit error rate testing as described in “Bit Error Rate Testing (BERT)” on page 3-44.

portFeature10GigWan 15 supports 10 Gbps Wide Area Network oper-ation.

portFeatureBertErrorGeneration 26 support Bert error generation

0 Invalid feature

portFeatureQos 1 QoS statistics available.

portFeaturePacketFlows 2 supports packet flow mode as described in “Streams and Flows” on page 3-4.

portFeatureUdfOddOffset 3 UDFs can occur at odd byte offsets.

portFeatureRxPacketGroups 4 supports packet group mode as described in “Packet Group Operation” on page 3-11.

portFeatureRxSequenceCheck-ing

5 supports receive sequence checking as described in “Sequence Checking Opera-tion” on page 3-13.

portFeatureRxDataIntegrity 6 supports received data integrity checking as described in “Data Integrity Checking Oper-ation” on page 3-13.

portFeatureRxRoundTripFlows 7 supports receive round trip flow mode as described in “Round Trip TCP Flows” on page 3-14.

portFeatureGigGMiiAutoDisable 8 Reserved for future usage.


portA

portFeatureMultipleDLCIs 9 supports ability to generate multiple DLCIs per port on frame relay connections

portFeatureForcedCollisions 10 supports forced collisions as described in “Forced Collision Operation” on page 3-10.

portFeatureTxDataIntegrity 11 supports transmitted data integrity as described in “Sequence Checking Opera-tion” on page 3-13.

portFeaturePacketFlowImageFile

12 supports packet flow mode with image files as described in the port command (this one).

portFeatureSrp 13 supports the spatial reuse protocol as described in “Sequence Checking Opera-tion” on page 3-13.

portFeaturePos 14 supports packet over sonet operation as described in “PPP Protocol Negotiation” on page 3-32.

portFeatureBert 15 supports bit error rate testing as described in “Bit Error Rate Testing (BERT)” on page 3-44.

portFeature10GigWan 16 supports 10 Gbps Wide Area Network oper-ation.

portFeature10GigWanAndOc192AndBert

17 supports 10 Gbps Wide Area Network, OC192 and BERT

portFeature10GigWanAndOc192 18 supports 10 Gbps Wide Area Network and OC192

portFeature10GigWanAndBert 19 supports 10 Gbps Wide Area Network and Bert

portFeatureOc192AndBert 20 supports OC 192 and Bert

portFeatureOC192Bert 21 supports OC192 Bert only

portFeatureUdfOverlap 22 multiple UDFs may start adjacent to each other, regardless of word boundaries

portFeatureUdfCascade 23 supports cascading of user defined fields as described in “Frame Data” on page 3-7.

portFeatureRxSequenceCheckingPerPGID

24 Sequence checking of packets with identical PGIDs is allowed

portFeaturePacketStreams 25 supports packet streams as described in “Streams and Flows” on page 3-4.

portFeatureAdvancedScheduler 26 supports advanced stream schedule opera-tion as described in “Streams and Flows” on page 3-4.

portFeatureProtocols 27 supports operation of the protocol server as described in “Protocol Server” on page 3-15.

portFeatureProtocolARP 28 supports ARP operation.

portFeatureProtocolPING 29 supports ping operation.

portFeatureBitMask 30 a bit mask may be used on UDF values without restriction; some boards require that bits in the mask be contiguous

portFeatureSonetErrorInsertionList

31 supports insertion of sonet errors

portFeatureBertErrorGeneration 34 support Bert error generation


port

port reset chasID cardID portIDRemoves all the streams on a port. Note: In order port reset to take effect, stream write or ixWriteConfigToHardware commands should be used to com-mit the changes to hardware. Specific errors are:


port restartAutoNegotiation chasID cardID portIDCauses auto-negotiation of duplex and speed to be restarted on the indicated port.

port set chasID cardID portIDSets the configuration of the port in IxHAL with id portID on card cardID, chas-sis chasID by reading the configuration option values set by the port config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• Insufficient memory to add data

port setDefault


port setFactoryDefaults chasID cardID portIDSets the factory defaults to the port. Specific errors are:


portFeatureLocalCPU 35 supports a local CPU

portFeatureIxRouter 36 can run a copy of IxRouter - used in IxWeb and other TCP level testing

portFeatureIxWeb 37 can be used in IxWeb

portFeature10GigLan 38 supports 10 gigabit ethernet LAN operation

portFeatureVsr 39 supports OC192 VSR operation

portFeatureSplitUdfs 40 UDFs may be split in combinations of 8, 16 and 32 bit counters

portFeatureTxDuration 41 supports the Transmit duration statistic

portFeatureRxTcpSessions 42 supports TCP sessions

portFeatureRxFirstTimeStamp 43 supports First TIme Stamp operation

portFeatureRxStreamTrigger 44 supports stream trigger operation

portFeatureRxChecksumErrors 45 supports receive checksum operation

portFeatureOddPreamble 46 supports an odd number of bytes in the pre-amble

portFeaturePacketGapTimeUnits 47 supports different units of time in the packet gap specification (gapUnit in stream).

portFeatureRoutingProtocols 48 supports the advanced routing protocols


portA

port setparm chasID cardID portIDModify the configuration options of the port on a specific card and chassis. It is similar to the port config option value command but allows a single option to be set in IxTclHAL on a particular port. NOTE: This command is being phased out. Please use port set command instead.

port setReceiveMode receiveMode chasID cardID portIDSets the receive mode on the port. See the description for receiveMode in the STANDARD OPTIONS section of this command for the values of receiveMode. Return codes are:

port setTransmitMode transmitMode chasID cardID portIDSets the transmission mode on the port. See the description for transmitMode in the STANDARD OPTIONS section of this command for the values of transmitMode. See the return codes in port setReceivedMode.

port write chasID cardID portIDWrites or commits the changes in IxHAL to hardware for each port with id portID on card cardID, chassis chasID. Before using this command, use the port set command to configure the port related parameters (speed, duplex mode, auto-negotiation, flow control, loopback, rxTxMode, and ignoreLink) in IxHAL. Spe-cific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Network error between the client and chassis

DEPRECATED COMMANDS

port writeReceiveMode chasID cardID portIDSets up the hardware to capture or packet group modes for this port.NOTE: OBSOLETE. This command is the same as write.

port writeTransmitMode chasID cardID portIDSets up the hardware to packet streams or packet flow mode for this port.NOTE: OBSOLETE. This command is the same as write.

Code Usage

0 (TCL_OK) The command succeeded and a write to hardware is needed, either with port write or ixWritePortsToHardware.

200 (ixTcl_noWriteRequired) No write is needed to set the mode, because the port is already in that mode.

101 (ixTcl_unsupportedFeature) This port type will not support the requested receive mode.

100 (ixTcl_notAvail) This port is owned by another user.


port



# Define all of the features by number and nameset pfValid [list \ $::portFeatureQos “Qos” \ $::portFeaturePacketFlows “Packet Flows” \ $::portFeatureUdfOddOffset “UDF odd offset” \ $::portFeatureRxPacketGroups “Rx packet groups” \ $::portFeatureRxSequenceChecking “Rx sequence checking” \ $::portFeatureRxDataIntegrity “Rx data integrity” \ $::portFeatureRxRoundTripFlows “Rx round trip flows” \ $::portFeatureGigGMiiAutoDisable “Gig GMII auto disable” \ $::portFeatureMultipleDLCIs “Multiple DLCIs” \ $::portFeatureForcedCollisions “Forced Collisions” \ $::portFeatureTxDataIntegrity “Tx Data Integrity” \ $::portFeaturePacketFlowImageFile “Packet flow image file” \ $::portFeatureSrp “Spacial reuse protocol” \ $::portFeaturePos “POS” \ $::portFeatureBert “Bert” \ $::portFeature10GigWan “10 Gigabit WAN” \ $::portFeatureUdfOverlap “UDF Overlap” \ $::portFeatureUdfCascade “UDF Cascade” \ $::portFeatureRxSequenceCheckingPerPGID “Rx Seq Checking per PGID” \ $::portFeaturePacketStreams “Packet Streams” \ $::portFeatureAdvancedScheduler “Advanced Scheduler” \ $::portFeatureProtocols “Protocols” \ $::portFeatureProtocolARP “Protocol: ARP” \ $::portFeatureProtocolPING “Protocol: PING” \ $::portFeatureBitMask “Bit Mask” \ $::portFeatureSonetErrorInsertionList “Sonet error insertion list” \ $::portFeatureBertErrorGeneration “BERT error generation” \]

# Define all of the features by number and nameset pfActive [list \ $::portFeatureRxPacketGroups “Rx packet groups” \ $::portFeatureRxDataIntegrity “Rx data integrity” \ $::portFeatureRxRoundTripFlows “Rx round trip flows” \ $::portFeaturePos “POS” \ $::portFeatureBert “Bert” \ $::portFeature10GigWan “10 Gigabit WAN” \ $::portFeatureBertErrorGeneration “BERT error generation” \]

# printOptions - get standard options for a port and print themproc printOptions {chas card port} \


portA

{ port get $chas $card $port set portType [port cget -type] set portName [port cget -typeName] set name [port cget -name] set owner [port cget -owner] set linkState [port cget -linkState] set rateMode [port cget -rateMode] set loopback [port cget -loopback] set flowControl [port cget -flowControl] set portMode [port cget -portMode] ixPuts “Port: $name, type $portName ($portType)” ixPuts “\towner $owner, linkState $linkState, rateMode $rateMode” ixPuts “\tloopback $loopback, flowControl $flowControl, portMode $portMode”}

# Print the values of all of the ‘valid’ featuresproc printValid {chas card port} \{ global pfValid; array set portValidFeatures $pfValid

foreach i [lsort -integer [array names portValidFeatures]] \ { if {[port isValidFeature $chas $card $port $i] == 0} \

{ ixPuts -nonewline “No “} \

else \{ ixPuts -nonewline “Yes “}

ixPuts $portValidFeatures($i) }}

# Print the values of all of the ‘active’ featuresproc printActive {chas card port} \{ global pfActive; array set portActiveFeatures $pfActive;

foreach i [lsort -integer [array names portActiveFeatures]] \ { if {[port isActiveFeature $chas $card $port $i] == 0} \

{ ixPuts -nonewline “No “} \

else \{ ixPuts -nonewline “Yes “}

ixPuts $portActiveFeatures($i) }}

# Get the chassis’ number of cardschassis getFromID $chasset ncards [chassis cget -maxCardCount]ixPuts “Chassis $chas, $ncards cards”


port

# Go through each of the portsfor {set i 1} {$i <= $ncards} {incr i} \{ # Check for missing card if {[card get $chas $i] != 0} \ { continue } ixPuts “\n------------------------------------------------------------” set portList [list [list $chas $i 1]]

# Get the port’s options port get $chas $i 1

# Get the type of the card as a number and name set portType [port cget -type] set portName [port cget -typeName] set cardType [card cget -type] ixPuts “Type $portName ($portType) -- card $i (type $cardType)”

# Set the port to its defaults port setDefault # If it’s a BERT module, need to set the transmit and receive modes to BERT if {$portType == $::portOc48Bert} \ { port config -transmitMode portTxModeBert port config -receiveMode portRxModeBert }

# Give the port a name port config -name “$i:1”

# Set the features to ixTclHal set result [port set $chas $i 1] # Check for valid result if {$result != 0} \ { ixPuts “Set returns $result” continue }

# Write the features to the hardware ixWriteConfigToHardware portList

# Print the standard options for the card printOptions $chas $i 1

# Print the valid features for the card ixPuts “\nValid Features for Port” ixPuts “-----------------------” printValid $chas $i 1

# Set some values for the 10/100 cards: # Rx:capture, Tx:packet flows w/ image file # Autonegotiate 100 Half or 100 Full duples if {$portType == $::port10100BaseTX} \ { port config -receiveMode portCapture port config -transmitMode portTxPacketFlows port config -usePacketFlowImageFile 1


portA

port config -packetFlowFileName “flow10100.txt” port config -autonegotiate true port config -advertise10HalfDuplex false port config -advertise10FullDuplex false port config -advertise100HalfDuplex true port config -advertise100FullDuplex true port config -speed 100 }

# Set some values for OC48c POS cards if {$portType == $::portPacketOverSonet} \ { port config -transmitMode portTxModeAdvancedScheduler port config -receiveMode portPacketGroup } # Set the values port set $chas $i 1 ixWriteConfigToHardware portList

# Check on what features are active now ixPuts “\nActive Features for Port” ixPuts “------------------------” printActive $chas $i 1

}

SEE ALSO card, filter, filterPallette, portGroup, stream, packetGroup


portGroup

NAME - portGroupportGroup - sets up a group of ports.

SYNOPSIS portGroup sub-command options

DESCRIPTION This command allows the user to set up an autonomous group of ports on which to perform an action or command, such as take ownership, start transmit, capture, or clearing statistics, to name a few. A port group must be created and the desired ports (or port) added to it in order to execute the selected action or command. When the port group is no longer needed, it should be destroyed.

STANDARD OPTIONS

lastTimeStamp Read-only. 64-bit value. The relative time of transmit for all the ports in the port group.

COMMANDS The portGroup command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

portGroup add groupID chasID cardID portIDAdds this port to a group with ID groupID. Specific errors are:

• No connection to a chassis• The groupID port group does not exist

portGroup canUse groupIDVerifies whether all the ports in this group can be used by the current logged in user. Specific errors are:


portGroup cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the portGroup command.

portGroup config option valueModify the configuration options of all the ports. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for portGroup. (There are currently no configurable options for portGroup and therefore no use for this command).

portGroup create groupIDCreates a port group and assigns it the ID groupID. Specific errors are:

• The groupID port group already exists

portGroup del groupID chasID cardID portID Deletes this port from the group with ID groupID. Specific errors are:


portGroupA


portGroup destroy groupIDDestroys the port group with ID groupID. Specific errors are:

• The groupID port group does not exist

portGroup get groupID objectIDGets the type of object designated by objectID for a list of ports. The only defined value for objectID is usbConfig (0), which must be applied to USB con-figured ports. Specific errors are:

• Invalid objectID• The groupID port group does not exist

portGroup setCommand groupID cmdPerforms the action or command cmd specified on all ports in the group with ID groupID. cmd may be one of the following:

Option Value Usage

startTransmit 7 start transmission on all ports in the portGroup simul-taneously

stopTransmit 8 stop transmission on all ports in the portGroup simul-taneously

startCapture 9 start capturing packets that meet the specified filter criteria

stopCapture 10 stop capturing on all ports in the portGroup simulta-neously

resetStatistics 13 clear all statistic counters

pauseTransmit 15 pause transmission

stepTransmit 16 single step the transmit one packet at a time

transmitPing 17 transmit a ping on all of the ports in the port group

asr5Transmit 18 not yet implemented

clearTimeStamp 19 clear all time stamps in order to synchronize the time stamps throughout the chassis chain.

restartAutoNegotiate 22 restarts autonegotiation

downloadFPGA 27 downloads a new FPGA to the ports in the port group

collisionStart 28 start collision generation

collisionStop 29 stop collision generation

transmitArpRequest 30 sends ARP requests as configured in arpServer and ipAddressTable commands.

startLatency 31 starts real-time latency analysis and collects mini-mum, maximum and average latency values for every incoming frame in a packet group

stopLatency 32 stops real-time latency analysis

clearLatency 33 clears all real-time latency values

takeOwnership 40 if available, take ownership of these ports

takeOwnershipForced 41 forcefully take ownership of these ports overriding the current owner’s rights

clearOwnership 42 clear ownership of owned ports


portGroup

Specific errors are:• No connection to a chassis• One or more ports in the port group are being used by another user• One or more ports in the port group are invalid• Network error between the client and chassis

portGroup setDefault


portGroup write groupIDCommits port properties information such as speed, duplex mode, and autonego-tiation in hardware. Specific errors are:

• No connection to a chassis• The port group specified by groupID hasn’t been created• One or more ports in the port group are being used by another user• Network error between the client and chassis

portGroup writeConfig groupIDConfigures streams, filter and capture parameters of all ports in the group except the port properties such as speed, duplex mode, and autonegotiation. Specific errors are:

• No connection to a chassis• The port group specified by groupID hasn’t been created• One or more ports in the port group are being used by another user• Network error between the client and chassis

clearOwnershipForced 43 forcefully clear ownership of ports overriding the cur-rent owner’s rights

staggeredStartTransmit 52 start transmit on all ports in the portGroup in sequence

transmitIgmpJoin 54 transmit IGMP join messages on all ports in the port-Group

transmitIgmpLeave 55 transmit IGMP join messages on all ports in the port-Group

resetSequenceIndex 62 resets the sequence number used in sequence num-ber checking operations for all ports in the portGroup

startBgp4 63 start BGP operations on all ports in the portGroup

stopBgp4 64 stop BGP operations on all ports in the portGroup

startOspf 65 start OSPF operations on all ports in the portGroup

stopOspf 66 stop OSPF operations on all ports in the portGroup

startIsis 76 start ISIS operations on all ports in the portGroup

stopIsis 77 stop ISIS operations on all ports in the portGroup

startRsvp 82 start RSVP operations on all ports in the portGroup

stopRsvp 83 stop RSVP operations on all ports in the portGroup

startRip 89 start RIP operations on all ports in the portGroup

stopRip 90 stop RIP operations on all ports in the portGroup

Option Value Usage


portGroupA



# Assume that there’s a four port 10/100 TX card in this slot# with port 1 looped to port 2 and 3 to 4set card 1

# Port group to be usedset group 1234set txGroup 13set rxGroup 24

portGroup create $groupportGroup add $group $chas $card 1portGroup add $group $chas $card 2portGroup add $group $chas $card 3portGroup add $group $chas $card 4

portGroup create $txGroupportGroup add $txGroup $chas $card 1portGroup add $txGroup $chas $card 3

portGroup create $rxGroupportGroup add $rxGroup $chas $card 2portGroup add $rxGroup $chas $card 4

ixLogin testerif {[portGroup canUse $group] != 0} \{ ixPuts “Can’t use card $card ports 1-4” break}portGroup setCommand $group takeOwnership

# ... insert port setup here. This example assumes the defaults

portGroup write $group

portGroup setCommand $rxGroup resetStatisticsportGroup setCommand $rxGroup startCaptureportGroup setCommand $txGroup startTransmit

after 5000portGroup setCommand $txGroup stopTransmitportGroup setCommand $rxGroup stopCapture

portGroup setCommand $group clearOwnershipportGroup destroy $groupportGroup destroy $rxGroupportGroup destroy $txGroupixLogout

SEE ALSO port


ppp

NAME - pppppp - configure Point-To-Point Protocol parameters

SYNOPSIS ppp sub-command options

DESCRIPTION This command is used to configure PPP parameters on OC-3 and OC-12 inter-faces for Packet over Sonet ports.

STANDARD OPTIONS

activeNegotiation true/false

Activate Negotiation process. (default = true)

configurationRetries Maximum number of configuration requests to send before starting termination process. (default = 9)

enable enable/disable Enable PPP negotiations. (default = disable)

enableAccmNegotiationenable/disable

Enables ACCM (Asynchronous Control Character Mask). (default = disable)

enableIp enable/disable

Enables the IP Network Control protocol. The port’s desired IP address is held in the localIPAddress option. (default = enable)

enableLqm enable/disable

Enables the LQM (Line Quality Monitoring Protocol). The LQM reporting inter-val is controlled by the lqmReportInterval option. (default = disable)

enableMpls enable/disable

Enables the MPLS Network Control protocol. (default = enable)

enableOsi enable/disable

Enables the OSI Network Control protocol. The port’s desired transmitted and received alignments are held in the rxAlignment and txAlignment options. (default = enable)

localIPAddress Local port’s IP address. (default = 0.0.0.1)

lqmReportInterval The desired LQM report interval, expressed in seconds. (default = 10)

retryTimeout Time, in seconds, to wait between configuration and termination retries. (default = 3)

rxAlignment The desired OSI receive byte alignment (within a 4-byte word), expressed as a byte position from 0 to 3. (default = 0)

rxMaxReceiveUnit Maximum frame size in receive direction. (default = 65535)

terminationRetries Maximum number of termination requests to send before bringing PPP down. (default = 3)

txAlignment The desired OSI transmit byte alignment (within a 4-byte word), expressed as a byte position from 0 to 3. (default = 0)


pppA

txMaxReceiveUnit Maximum frame size in transmit direction. (default = 65535)

useMagicNumber true/false

Enable negotiation and use of magic number; used to detect looped back connection. (default = false)

COMMANDS The ppp command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

ppp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ppp command.

ppp config option valueModify the PPP configuration options of the port. If no option is specified, returns a list describing all of the available PPP options (see STANDARD OPTIONS) for port.

ppp get chasID cardID portIDGets the current configuration of the PPP parameters on port with id portID on card cardID, chassis chasID. from its hardware. Call this command before call-ing ppp cget option value to get the value of the configuration option. Specific errors are:


ppp set chasID cardID portIDSets the configuration of the PPP parameters in IxHAL on port with id portID on card cardID, chassis chasID by reading the configuration option values set by the ppp config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• The port is not a Packet over Sonet port.

ppp setDefault


ppp write chasID cardID portIDWrites the ppp config to the ppp state machine and restarts ppp autonegotiation. Writes or commits the changes in IxHAL to hardware for each port with id portID on card cardID, chassis chasID. Before using this command, use the ppp set command to configure the port related parameters in IxHAL. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• Network error between the client and chassis• The port is not a Packet over Sonet port


ppp


# Procedure to get and print the status of a POS portproc getState {chas card port} \{ # Get all of the status information pppStatus get $chas $card $port # IP related information set ipState [pppStatus cget -ipState] set ipAddr [pppStatus cget -localIPAddress] set ipPeerAddr [pppStatus cget -peerIPAddress]

# LQM State information set lqmState [pppStatus cget -lqmQualityState] set lqmRxInterval [pppStatus cget -lqmReportIntervalRx] set lqmTxInterval [pppStatus cget -lqmReportIntervalTx]

# MPLS state set mplsState [pppStatus cget -mplsState]

# OSI information set osiState [pppStatus cget -osiState] set rxAlignment [pppStatus cget -rxAlignment] set txAlignment [pppStatus cget -txAlignment]

# Magic numbers set magicRxState [pppStatus cget -useMagicNumberRx] set magicTxState [pppStatus cget -useMagicNumberTx]

# Negotiated MRUs set rxMRU [pppStatus cget -rxMaxReceiveUnit] set txMRU [pppStatus cget -txMaxReceiveUnit]

ixPuts “Port $chas:$card:$port” ixPuts “\tMRU:\trxMaxReceiveUnit $rxMRU, txMaxReceiveUnit $txMRU” ixPuts “\tMagic:\tuseMagicNumberRx $magicRxState, useMagicTxSate $magicTxState” ixPuts “\tLQM:\tlqmReportIntervalRx $lqmRxInterval, lqmReportIntervalTx $lqmTxInterval” ixPuts “\tIP:\tstate $ipState, localIpAddress $ipAddr, peerIpAddress $ipPeerAddr” ixPuts “\tOSI:\tstate $osiState, rxAlignment $rxAlignment, txAlignment $txAlignment” ixPuts “\tMPLS:\tstate $mplsState”}

# Symbolic definition of the PPP related port link states# Not all states are necessarily definedset pppState($::pppOff) “pppOff\t”set pppState($::pppUp) “pppUp\t”set pppState($::pppDown) “pppDown\t”set pppState($::pppInit) “pppInit\t”set pppState($::pppWaitForOpen) “pppWaitForOpen”set pppState($::pppAutoNegotiate) “pppAutoNegotiate”set pppState($::pppClose) “pppClose”set pppState($::pppConnect) “pppConnect”set pppState($::pppRestartNegotiation) “pppRestartNegotiation”set pppState($::pppRestartInit) “pppRestartInit”set pppState($::pppRestartWaitForOpen) “pppRestartWaitForOpen”set pppState($::pppRestartWaitForClose) “pppRestartWaitForClose”


pppA

set pppState($::pppRestartFinish) “pppRestartFinish”set pppState($::pppClosing) “pppClosing”set pppState($::pppLcpNegotiate) “pppLcpNegotiate”set pppState($::pppAuthenticate) “pppAuthenticate”set pppState($::pppNcpNegotiate) “pppNcpNegotiate”


# Assuming that an OC12 card is in slot 2# And that port 1 is directly connected to port 2set card 2

# Get the type of card and check if it’s the correct typeset ifType [card getInterface $chas $card]if {$ifType != $::interfacePacketOverSonet} \{ ixPuts “Card $card is not an OC12c POS card”} \else \{ # Disable PPP negotiation and tell both ports to stop ppp config -enable disable ppp set $chas $card 1 ppp set $chas $card 2 ppp write $chas $card 1 ppp write $chas $card 2

# Start with a default setup, enable PPP and set auto negotiatoin ppp setDefault ppp config -enable enable ppp config -activeNegotiation true

# Enable IP address negotation and set our desired IP address ppp config -enableIp enable ppp config -localIPAddress 192.168.5.100

# Enable MPLS negotiation ppp config -enableMpls enable

# Enable magic number negotiation ppp config -useMagicNumber true

# Enable LQM and set the desired report interval to 5 seconds ppp config -enableLqm enable ppp config -lqmReportInterval 5

# Enable OSI negotiation with alignment at byte 2 ppp config -enableOsi enable ppp config -rxAlignment 2 ppp config -txAlignment 2

# Set PPP parameters to port 1 ppp set $chas $card 1 ppp write $chas $card 1

# When two Ixia ports are connected directly, only one can use recovered clock sonet setDefault sonet config -useRecoveredClock false


ppp

sonet set $chas $card 1 ixWritePortsToHardware { {$chas $card 1} } # Change the requested address for the second port ppp config -localIPAddress 192.168.6.100 ppp set $chas $card 2 ppp write $chas $card 2

# Now monitor and print the port link state until both ports show up or a minute # Has gone by ixPuts “Link state monitoring” ixPuts “Port 1\t\t\tPort 2” ixPuts “------\t\t\t------” for {set i 0} {$i < 60} {incr i} \ {

after 1000 port get $chas $card 1

set portState1 [port cget -linkState] port get $chas $card 2

set portState2 [port cget -linkState]ixPuts “$pppState($portState1)\t\t$pppState($portState2)”if {$portState1 == $::pppUp && $portState2 == $::pppUp}

{break} } # If both ports went to pppUp, then get and print the state for each if {$portState1 == $::pppUp && $portState2 == $::pppUp} \ { getState $chas $card 1 getState $chas $card 2 }}

SEE ALSO pppStatus


pppStatusA

NAME - pppStatuspppStatus - configure PPP parameters

SYNOPSIS pppStatus sub-command options

DESCRIPTION This command gets PPP status information for Packet over Sonet ports.

STANDARD OPTIONS

ipState Read-only. The current state of the IP Network Control Protocol negotiation. One of:

lqmReportPacketCounterRx

Read-only. The number of LQM report packets received since link was last estab-lished.

lqmReportPacketCounterTx

Read-only. The number of LQM report packets transmitted since link was last established.

localIPAddress Read-only. The negotiated local IP address for the port as a result of the IP Net-work Control Protocol’s operation.

lqmReportIntervalRx Read-only. The negotiated LQM receive port interval, expressed in seconds.

lqmReportIntervalTx Read-only. The negotiated LQM transmit port interval, expressed in seconds.

lqmQualityState Read-only. The current state of the LQM negotiation. One of:

State Value Usage

pppStatusDisabled 0 The IPCP protocol has been disabled and will not be negotiated during the NCP phase.

pppStatusClose 1 The IPCP protocol is enabled but is currently closed. IPCP traffic will be dropped.

pppStatusNegotiation 2 The IPCP protocol is currently being negotiated on the link. This state may continue indefinitely if the peer refuses to negotiate IPCP.

pppStatusOpen 3 The IPCP protocol is currently open and IPCP traffic may flow.

State Value Usage

pppStatusNotNegotiated 0 The LQM option has been locally disabled and will not be negotiated. Any subsequent Link Quality Reports (LQR) received on the link will be ignored.

pppStatusInactive 1 LQM is not running on the link and any LQRs received will be ignored.

pppStatusActive 2 LQM operation was agreed to by both peers during LCP negotiation and LQM is running on the link. LQRs received on the link will be pre-processed and local LQRs will be generated and sent.


pppStatus

magicNumberNegotiated

Read-only. The magic number negotiated between the local and remote hosts. (default = 0)

mplsState Read-only. The current state of the MPLS Network Control Protocol negotiation. One of:

osiState Read-only. The current state of the OSI Network Control Protocol negotiation. One of:

peerIPAddress Read-only. The negotiated IP address of the peer.

rxAlignment Read-only. The negotiated OSI receive alignment.

rxMaxReceiveUnit Read-only. Maximum frame size in receive direction. (default = 0)

txAlignment Read-only. The negotiated OSI receive alignment.

txMaxReceiveUnit Read-only. Maximum frame size in transmit direction. (default = 0)

useMagicNumberRx Read-only. The current state of the receive magic number negotiation. One of:

State Value Usage

pppStatusDisabled 0 The MPLS NCP protocol has been disabled and will not be negotiated during the NCP phase.

pppStatusClose 1 The MPLS NCP protocol is enabled but is currently closed. MPLS NCP traffic will be dropped.

pppStatusNegotiation 2 The MPLS NCP protocol is currently being negoti-ated on the link. This state may continue indefinitely if the peer refuses to negotiate MPLS NCP.

pppStatusOpen 3 The MPLS NCP protocol is currently open and IPCP traffic may flow.

State Value Usage

pppStatusDisabled 0 The OSI NCP protocol has been disabled and will not be negotiated during the NCP phase.

pppStatusClose 1 The OSI NCP protocol is enabled but is currently closed. OSI NCP traffic will be dropped.

pppStatusNegotiation 2 The OSI NCP protocol is currently being negotiated on the link. This state may continue indefinitely if the peer refuses to negotiate OSI NCP.

pppStatusOpen 3 The OSI NCP protocol is currently open and IPCP traffic may flow.

State Value Usage

pppStatusDisabled 0 The negotiation of received Magic Number has been disabled and will not be negotiated during the NCP phase.

pppStatusClose 1 The negotiation of received Magic Number is enabled but is currently closed. Related traffic will be dropped.

pppStatusNegotiation 2 The received Magic Number is currently being nego-tiated on the link. This state may continue indefinitely if the peer refuses to negotiate.


pppStatusA

useMagicNumberTx Read-only. The current state of the transmit magic number negotiation. One of:

COMMANDS The pppStatus command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

pppStatus cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the pppStatus command.

pppStatus config option valueModify the configuration options. If no option is specified, returns a list describ-ing all of the available options (see STANDARD OPTIONS) for pppStatus.

pppStatus get chasID cardID portIDGets the current PPP Status information on port with id portID on card cardID, chassis chasID from its hardware. Call this command before calling pppStatus cget option value to get the value of the configuration option.

EXAMPLES See examples under ppp

SEE ALSO ppp

pppStatusOpen 3 The negotiation of received Magic Number is cur-rently open and related traffic may flow.

State Value Usage

State Value Usage

pppStatusDisabled 0 The negotiation of transmitted Magic Number has been disabled and will not be negotiated during the NCP phase.

pppStatusClose 1 The negotiation of transmitted Magic Number is enabled but is currently closed. Related traffic will be dropped.

pppStatusNegotiation 2 The transmitted Magic Number is currently being negotiated on the link. This state may continue indef-initely if the peer refuses to negotiate.

pppStatusOpen 3 The negotiation of transmitted Magic Number is cur-rently open and related traffic may flow.


protocol

NAME - protocolprotocol - configure the type of protocol to use for running the tests.

SYNOPSIS protocol sub-command options

DESCRIPTION This command allows the user to select the ethernet frame type and protocol type to use when building data packets or running a test. NOTE: In order to set these values in IxHal and to commit them to the hardware use stream set and stream write.

STANDARD OPTIONS

appName The application running on top of IP. These are applications may be layer 3 or 5 and others that cannot be directly set in the IP header. To use layer 4 applications such as UDP and TCP, use ip config –ipProtocol command. Available options are:

dutStripTag true/false (default = true)

enable802dot1qTag true/false

Enable 802.1q Vlan tagged frame insertion. (default = false)

enableISLtag true/false Enable Cisco ISL Tagged frame insertion. (default = false)

enableMPLS true/false Enable MPLS Tagged frame insertion. (default = false)

ethernetType The type of ethernet frame selected. Options include:

Option Value Usage

0 (default)

udp 5

Arp 8

Rip 11

Dhcp 13

Option Value Usage

noType 0 (default)

ethernetII 1

ieee8023 2

ieee8023snap 3

ieee8022 15


protocolA

name The name of the protocol selected. Options include:

COMMANDS The protocol command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

protocol cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the protocol command.NOTE: Call command stream get chasID cardID portID streamID before call-ing protocol cget option value to get the value of the configuration option.

protocol config option valueModify the configuration options of the port. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for port.

protocol setDefault





# Set to ethernet II and ipV4protocol setDefaultprotocol config -name ipV4protocol config -ethernetType ethernetII

Option Value Usage

mac 0 MAC layer 2. During the learn process, simple MAC frames that contain the MAC address of the receive ports will be transmitted to allow the switch to learn the ports (default)

ip 4 Uses an IP version 4 header in the frame, see ip command set. If name is set to ip, during the learn process ARP frames from both the transmit and receive ports will be sent to DUT. From the ARP frames, the DUT will learn the IP address of the attached Ixia ports and the Ixia ports will learn the MAC address of the DUT port.

ipV4 4 same as ip above.

ipx 7 Uses an IPX header in the frame, see ipx command set. During the learn process, RIPx frames both the transmit and receive ports will be sent to DUT so it may learn the network address of the attached ports and so that the transmit ports may learn the MAC address of the attached DUT port.

ipV6 31 Uses an IP version 6 header in the frame.


protocol

# Protocol values are saved via the stream commandstream set $chas $card $port 1


SEE ALSO stream, ip, ipx


protocolServerA

NAME - protocolServerprotocolServer - configure the protocol server services for a port.

SYNOPSIS protocolServer sub-command options

DESCRIPTION This command allows the user to select a protocol service and configure that ser-vice. The protocol server is used to enable and disable the ability to respond to ARP and Ping requests received from DUTs.

STANDARD OPTIONS

enableArpResponsetrue / false

Enable ARP response. (default = false)

enableBgp4Servicetrue / false

Enable BGP4 service. (default = false)

enableIgmpQueryResponse true / false

Enable IGMP query response. (default = false)

enableIsisServicetrue / false

Enable ISIS service. (default = false)

enableOspfServicetrue / false

Enable OSPF service. (default = false)

enablePingResponsetrue / false

Eable PING response. (default = false)

enableRipServicetrue / false

Enable RIP service. (default = false)

enableRsvpServicetrue / false

Enable RSVP service. (default = false)

DEPRECATED STAN-DARD OPTIONS

arpServerEnable true/false

Enable the ARP response engine to send out ARP responses when ARP requests are received on a port. (default = false)

count The total number of addresses in the address table.

IpAddress Initial IP address for the protocol server address table.

MacAddress Initial MAC address for the protocol server address table.


protocolServer

mapType The type of mac/ip address mapping selected. Options include:

pingServerEnable true/false

Enable the PING response engine to send out PING responses when PING requests are received on a port. (default = false)

rate (default = -1)

repeatCount (default = -1)

COMMANDS The protocolServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

protocolServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the protocolServer command.

protocolServer config option valueModify the configuration options of the protocolServer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for protocolServer.

protocolServer get chasID cardID portIDGets the current configuration of the protocol server on port with id portID on card cardID, chassis chasID. from its hardware. Call this command before call-ing protocolServer cget option value to get the value of the configuration option. Specific errors are:


protocolServer set chasID cardID portIDSets the current configuration of the protocol server on port with id portID on card cardID, chassis chasID. from its hardware. Call this command before call-ing protocolServer cget option value to get the value of the configuration option. Specific errors are:


protocolServer setDefault


Option Value Usage

oneIpToOneMAC 0 Exactly one MAC address will be associated with each IP address (default)

manyIpToOneMAC 1 Only one MAC address will be associated with multi-ple IP addresses


protocolServerA

protocolServer write chasID cardID portIDWrites or commits the changes in IxHAL to hardware the protocol server config-uration for each port with id portID on card cardID, chassis chasID. Before using this command, use the protocolServer set command to configure the port related in IxHAL. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• Network error between the client and chassis

EXAMPLES See examples under arpServer, bgp4Server, igmpServer, isisServer, ospfServer, ripServer, and rsvpServer

SEE ALSO protocol, port


qos

NAME - qosqos - configure the QoS counter parameters for a port

SYNOPSIS qos sub-command options

DESCRIPTION This command allows the user to set up the QoS counter filters and offset of the QoS priority bits.

STANDARD OPTIONS

byteOffset The offset where the priority value is checked to indicate which of the QoS counters is going to be incremented. (default = 14)

packetType Read-only. The type of packet that the QoS counters are looking for priority bits within. One of:

patternMask The mask of the pattern that is analyzed by the Receive engine to increment the QoS counter. (default = 00 00)

patternMatch The pattern that is analyzed by the Receive engine to increment the QoS counter. (default = 81 00)

patternOffset The offset where the pattern to be matched is located. (default = 12)

COMMANDS The qos command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

qos cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the qos command

qos config option valueModify the configuration options of the qos. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for qos.

qos get chasID cardID portIDGets the current configuration of the QoS counters on port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling qos cget option value to get the value of the configuration option. Specific errors are:

Option Value Usage

ipEthernetII 0

ip8023Snap 1

vlan 2

custom 3

ipPpp 4

ipCiscoHdlc 5


qosA


qos set chasID cardID portIDSets the configuration of the QoS counters in IxHAL on port with id portID on card cardID, chassis chasID by reading the configuration option values set by the qos config option value command. Specific errors are:


qos setDefault


qos setup packetTypeSets the QoS counters to look for priority bits for a certain type of packet. See the packetType standard option description for the choices. Specific errors are:

• Invalid packetType

qos write chasID cardID portIDWrites or commits the changes in IxHAL to hardware the QoS counters configu-ration for each port with id portID on card cardID, chassis chasID. Before using this command, use the qos set command to configure the port related parameters (byteOffset, patternMatch, patternMask, patternOffset) in IxHAL. Specific errors are:



# In this test, we’ll generate a number of packets with different# settings in the QoS field. The directly connected receiving port# will be set to receive and provide statistics for the number of # QoS packets received at each of 8 levels


# Assume card to be used is in slot 1set card 1set txPort 1set rxPort 2set portList [list [list $chas $card $txPort] \ [list $chas $card $rxPort] ]

# Setup port 1 to transmitport setFactoryDefaults $chas $card $txPortport setDefault

# Stream: 100,000 packetsstream setDefaultstream config -numFrames 100000stream config -dma stopStream


qos

# IP/ethernetII packetsip setDefaultip set $chas $card $txPort


# Overlay UDF1 on top of the QoS byte with an appropriate maskudf setDefaultudf config -enable trueudf config -offset 15udf config -countertype c8udf config -continuousCount trueudf config -maskselect {1F 00 00 00}udf set 1


# Set up port 2 for QoS Statisticsport setFactoryDefaults $chas $card $rxPortport setDefault

# QoS statistics modestat config -mode statQosstat set $chas $card $rxPort

# Set up locations of where to find the informationqos setup ipEthernetIIqos set $chas $card $rxPort

protocol setDefaultprotocol config -name macprotocol config -ethernetType ethernetII

port set $chas $card $rxPort

# Write config to hardwareixWritePortsToHardware portList

# Clear stats, run the transmissionafter 1000ixClearPortStats $chas $card $rxPortixStartPortTransmit $chas $card $txPortafter 1000ixCheckPortTransmitDone $chas $card $txPort

# Get the 8 QoS statistics and print themstat get allStats $chas $card $rxPort

for {set i 0} {$i <= 7} {incr i} \{ ixPuts -nonewline “Qos$i = “ ixPuts [stat cget -qualityOfService$i]}

SEE ALSO stat, port


ripA

NAME - riprip - configure the RIP header parameters for a port on a card on a chassis

SYNOPSIS rip sub-command options

DESCRIPTION The rip command is used to configure the RIP header information used when building RIP-type packets. See RFCs 1058 and 1723 for a complete definition of RIP header fields.

STANDARD OPTIONS

command The command field of the RIP header. Defined values include:

version The version field of the RIP header. Defined values include:

COMMANDS The rip command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

rip cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rip command.

rip config option valueModify the RIP configuration options of the port. If no option is specified, returns a list describing all of the available RIP options (see STANDARD OPTIONS) for port.

rip decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. rip cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used. Specific errors are:


Option Value Usage

ripRequest 1 (default) a request for the responding system to send all or part of its routing table

ripResponse 2 response or update information from a sender

ripTraceOn 3 an obsolete message

ripTraceOff 4 an obsolete message

ripReserved 5 reserved for use by Sun Microsystems

Option Value Usage

ripVersion1 1

ripVersion2 2 (default)


rip

• The captured frame is not a valid Rip frame

rip get chasID cardID portIDGets the current RIP configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling rip cget option to get the value of the configuration option. Specific errors are:


rip set chasID cardID portIDSets the RIP configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the rip config option value command. Specific errors are:


rip setDefault



# In this example weíll generate a RIP packet with two route# specifications


# Assume card to be used is in slot 1set card 1set port 1set portList [list [list $chas $card $port]]

# Put the port in loopback modeport setFactoryDefaults $chas $card $portport setDefault

# Stream: 1 packet at 1%stream setDefaultstream config -numFrames 1stream config -dma stopStreamstream config -rateMode usePercentRatestream config -percentPacketRate 1

# Set up IP: icmp with 46 byte packetip setDefaultip config -ipProtocol udpip config -totalLength 72ip set $chas $card $port

# Set up protocolprotocol setDefaultprotocol config -ethernetType ethernetII


ripA

protocol config -name ipV4protocol config -appName Rip

# Set up UDPudp setDefaultudp config -sourcePort ripPortudp config -destPort ripPortudp set $chas $card $port

# Set up Rip in generalrip setDefaultrip config -command ripResponserip config -version 2# Set up Rip RoutesripRoute setDefaultripRoute config -familyId 2ripRoute config -routeTag 0ripRoute config -metric 10ripRoute config -ipAddress 192.168.36.1ripRoute config -subnetMask 255.255.255.0ripRoute config -nextHop 192.168.46.254ripRoute set 1

ripRoute config -metric 20ripRoute config -ipAddress 0.0.0.0ripRoute config -nextHop 192.168.46.1ripRoute set 2

rip set $chas $card $port



SEE ALSO port, protocol, ip, ripRoute


ripRoute

NAME - ripRouteripRoute - configure the RIP routing parameters for a port on a card on a chassis

SYNOPSIS ripRoute sub-command options

DESCRIPTION The ripRoute command is used to configure the RIP routing parameters used when building RIP packets. See RFCs 1058 and 1723 for a complete definition of RIP.

STANDARD OPTIONS

authentication Authentication string, maximum 16 octets. (default = ““)

authenticationType Type of authentication. (default = 2)

familyId Address family identifier. Valid values are 2 (IP protocol), OxFFFF (authentication entry, automatically sets if ripRoute setAuthentication called). (default = 00)

ipAddress IP address of the routing table entry. (default = 0.0.0.0)

metric The routing cost metric, from 1 to 16 with 16 interpreted as unreachable. (default = 1)

nextHop For version 2 records, the IP address of the next routing hop for the IP address and subnet mask. (default = 0.0.0.0)

routeTag The number used to distinguish the source of routing destination. (default = 00)

subnetMask Subnet mask for this route. (default = 0.0.0.0)

COMMANDS The ripRoute command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ripRoute cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ripRoute command.

ripRoute config option valueModify the ripRoute configuration options of the port. If no option is specified, returns a list describing all of the available ripRoute options (see STANDARD OPTIONS) for port.

ripRoute get routeIDGets the current route configuration of the selected routeID. Call this command before calling ripRoute cget option to get the value of the configuration option. Specific errors are:

• The specified route does not exist


ripRouteA

ripRoute remove routeIDRemove the route routeID from the routing table.Specific errors are:

• The specified route does not exist

ripRoute set routeIDSets the route configuration for route routeID reading the configuration option values set by the ripRoute config option value command. Specific errors are:

• The configured parameters are not valid for this port• Insufficient memory to add the new route

ripRoute setAuthentication authenticationSets an authentication route as the first entry of the routing table with familyID set to 0xFFFF. Specific errors are:

• The parent rip structure does not exist• Insufficient memory

ripRoute setDefault


EXAMPLES See examples under rip

SEE ALSO stream, protocol, ip, rip


ripInterfaceRouter

NAME - ripInterfaceRouterripInterfaceRouter - configure an RIP router

SYNOPSIS ripInterfaceRouter sub-command options

DESCRIPTION The ripInterfaceRouter command represents a simulated router. In addition to some identifying options, it holds a list for the router:

• Route ranges – routes to be advertised by the simulated router, con-structed in the ripRouteRange command.

Routers defined in this command are added to an ripServer using the ripServer addRouter command. Refer to “ripInterfaceRouter” on page 5-81 for an over-view of this command.

STANDARD OPTIONS

authorizationPassword If enableAuthorization is true, then this is the password to be included in the authentication part of the RIP messages. (default = ““)

enableAuthorizationtrue / false

Indicates whether authorization is included in update messages. (default = false)

enableRoutertrue / false

Enables or disables the simulated router. (default = false)

ipAddress The IP address of the simulated RIP router. (default = 0.0.0.0)

ipMask The network mask associated with the ipAddress. (default = 255.255.255.255)

receiveType Filters the version of messages this router will receive. One of:

responseMode One of:

The current implementation uses ripSplitHorizonSpaceSaver as its update mode regardless of the setting.

Option Value Usage

ripReceiveVersion1 1 RIP Version 1 messages only.

ripReceiveVersion2 2 (default) RIP Version 2 messages only.

ripReceiveVersion1and2 3 Both RIP version messages.

ripDefault 0

ripSplitHorizon 1

ripPoisonReverse 2

ripSplitHorizonSpaceSaver 3 (default)

ripSilent 4


ripInterfaceRouterA

sendType The method for sending RIP packets. One of:

updateIntervalOffset A random percentage of this time value, expressed in seconds,which will be added or subtracted from the update interval. (default = 5)

updateInterval The time, in seconds, between transmitted update messages. (default = 30)

COMMANDS The ripInterfaceRouter command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

ripInterfaceRouter addRouteRange routeRangeIdAdds the route range described in the ripRouteRange command to the list of route ranges associated with the router. The range’s entry in the list is given an identifier of routeRangeId. Specific errors are:

• The parameters in ripRouteRange are invalid• A router with this routeRangeId exists already in the list

ripInterfaceRouter cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ripInterfaceRouter command.

ripInterfaceRouter clearAllRouteRange


ripInterfaceRouter config option valueModify the configuration options of the ripInterfaceRouter. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for ripInterfaceRouter.

ripInterfaceRouter delRouteRange routeRangeIdDeletes the route range with an identifier of routeRangeId. Specific errors are:

• No router with this routeRangeId exists in the list

ripInterfaceRouter getFirstRouteRange

Access the first route range in the list. The results may be accessed using the ripRouteRange command. Specific errors are:


ripInterfaceRouter getNextRouteRange

Access the next route range in the list. The results may be accessed using the ripRouteRange command. Specific errors are:

• ripInterfaceRouter getFirstRouteRange hasn’t been called

Option Value Usage

ripMulticast 0 (default) sends Version 2 packets via multicast

ripBroadcastV1 1 sends V1 packets via broadcast.

ripBroadcastV2 2 sends V2 packets via broadcast.


ripInterfaceRouter

• There is no more route ranges in the list

ripInterfaceRouter getRouteRange routeRangeIdAccesses the range’s entry in the list with an identifier of routeRangeId. The router range is accessed in the ripRouterRange command. Specific errors are:

• A router with this routeRangeId does not exist in the list

ripInterfaceRouter setDefault


ripInterfaceRouter setRouteRange routeRangeIdSets the values for the route range’s entry in the list with an identifier of routeRangeId based on changes made through the ripRouteRange command. This command should be used to change a running configuration and must be followed by a ripServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A router with this routeRangeId does not exist in the list

EXAMPLES See examples under ripServer.

SEE ALSO ripServer, ripRouteRange


ripRouteRangeA

NAME - ripRouteRangeripRouteRange -sets up the parameters associated with an RIP route range.

SYNOPSIS ripRouteRange sub-command options

DESCRIPTION This command describes a set of routes. Route ranges are added into ripInterfac-eRouter lists using the ripInterfaceRouter addRouteRange command. Refer to “ripRouteRange” on page 5-83 for an overview of this command.

STANDARD OPTIONS

enableRouteRange Enables the use of this route range for the simulated router. (default = 0)

metric The total metric cost for these routes. The valid range is from 1 to 16 (inclusive). A value of 16 means that the destination is not reachable, and that route will be removed from service. (default = 1)

networkIpAddress The network address to be used in creating this route range. (default = 0.0.0.0)

networkMaskWidth The network mask to be applied to the networkIpAddress to yield the non-host part of the address. A value of 0 means there is no subnet address. (default = 0)

nextHop The immediate next hop IP address on the way to the destination address. (default = 0.0.0.0)

numberOfNetworks The number of networks to be generated for this route range, based on the network address plus the network mask. (default = 0)

routeTag A arbitrary value associated with the routes in this range. It is used to provide a means for distinguishing internal vs. external RIP routes. (default = 0)

COMMANDS The ripRouteRange command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ripRouteRange cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ripRouteRange command.

ripRouteRange config option valueModify the configuration options of the ripRouteRange. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ripRouteRange.

ripRouteRange setDefault


EXAMPLES See examples under ripServer.

SEE ALSO ripServer, ripInterfaceRouter


ripServer

NAME - ripServerripServer - access the RIP component of the Protocol Server for a particular port.

SYNOPSIS ripServer sub-command options

DESCRIPTION The ripServer command is necessary in order to access the RIP Protocol Server for a particular port. The select sub-command must be used before all other RIP commands. Refer to “ripServer” on page 5-80 for an overview.

STANDARD OPTIONS

none

COMMANDS The ripServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ripServer addRouter routerIdAdds the RIP router described in the ripInterfaceRouter command to the list of routers associated with the port. The router’s entry in the list is given an identifier of routerId. Specific errors are:

• ripServer select hasn’t been called• The router parameters in ripInterfaceRouter are invalid• A router with this routerId exists already in the list

ripServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the ripServer command.

ripServer clearAllRouter

Deletes all the RIP routers in the list. Specific errors are: • ripServer select hasn’t been called

ripServer config option valueModify the configuration options of the ripServer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for ripServer.

ripServer delRouter routerIdDeletes the RIP router described that has an identifier of routerId. Specific errors are:

• ripServer select hasn’t been called• There is no router with this routerId in the list


ripServerA

ripServer getFirstRouter

Access the first RIP router in the list. The results may be accessed using the rip-InterfaceRouter command. Specific errors are:

• ripServer select hasn’t been called• There are no routers in the list

ripServer getNextRouter

Access the next RIP router in the list. The results may be accessed using the rip-InterfaceRouter command. Specific errors are:

• ripServer select hasn’t been called• ripServer getFirstRouter hasn’t been called• There is no more routers in the list

ripServer getRouter routerIdAccess the RIP router with an identifier of routerId. The results may be accessed using the ripInterfaceRouter command. Specific errors are:

• ripServer select hasn’t been called• There is no router with this routerId in the list

ripServer select chasID cardID portIDAccesses the RIP component of the Protocol server for the indicated port. Spe-cific errors are:

• No connection to the chassis• The RIP protocol package has not been installed• Invalid port specified

ripServer setRouter routerLocalIdSets the values for the router’s entry in the list with an identifier of routerLocalId based on changes made through the ripInterfaceRouter command. This com-mand should be used to change a running configuration and must be followed by an ripServer write command in order to send these changes to the Protocol Server. Specific errors are:


ripServer write

Writes or commits the changes in IxHAL to hardware for the currently selected chassis, card and port. Before using this command, use the ripServer select com-mand to select the port.


# Port is chassis 1, card 1, port 1 with a MAC addr of# 00 0a de 00 01 01set card 1set port 1set pl [list [list 1 $card $port]]set myMac [format “00 0a de 00 %02x %02x” $card $port]

# The router being simulated on the portset router 198.18.1.2


ripServer

# Basic parameters for the RIP routerset mask 255.255.255.0set sendType ripBroadcastV2set receiveType ripReceiveVersion2set updateInterval 30set updateIntervalOffset 5

An array of multiple route ranges, organized as a table# Num # RangeIp Prefix Routes Metric Next Hop Tagset routeRanges {{10.0.0.0 13 1000 4 198.18.1.2 9} \ {20.0.0.0 17 1000 4 198.18.1.2 10}}

ixInitialize hiwire

# Initialize portport setFactoryDefaults 1 $card $portport setDefaultport set 1 $card $port

# Select the port and clear all defined routersripServer select 1 $card $portripServer clearAllRouters

set routerId 1set rangeId 1

# For all the defined routerswhile {[llength $routeRanges] > 0} { # Extract the information from the table and set the route ranges scan [lindex $routeRanges 0] “%s %s %s %s %s %s” \ myIp prefix numRoutes metric nextHop routeTag ripRouteRange setDefault ripRouteRange config -enableRouteRange true ripRouteRange config -routeTag $routeTag ripRouteRange config -networkIpAddress $myIp ripRouteRange config -networkMaskWidth $prefix ripRouteRange config -numberOfNetworks $numRoutes ripRouteRange config -nextHop $nextHop ripRouteRange config -metric $metric

# Create a name for each individual route range ripInterfaceRouter addRouteRange \ [format “routeRange%02d” $rangeId] incr rangeId set routeRanges [lrange $routeRanges 1 end]}

# Now set the basic parameters for the routerripInterfaceRouter setDefault ripInterfaceRouter config -enableRouter trueripInterfaceRouter config -ipAddress $routerripInterfaceRouter config -ipMask $maskripInterfaceRouter config -sendType $sendTyperipInterfaceRouter config -receiveType $receiveTyperipInterfaceRouter config -updateInterval $updateIntervalripInterfaceRouter config -updateIntervalOffset $updateIntervalOffset

# And add the router to the ripServer with a unique IDripServer addRouter [format “router%02d” $routerId]


ripServerA

# Set up the IP address table, arp server and protocol server# To respond to arps from the routeripAddressTableItem setDefault ipAddressTableItem config -numAddresses 1ipAddressTableItem config -mappingOption oneIpToOnemyMacipAddressTableItem config -overrideDefaultGateway falseipAddressTableItem config -fromIpAddress $routeripAddressTableItem config -fromMacAddress $myMacipAddressTable addItemipAddressTable set 1 $card $port

arpServer setDefault arpServer config -mode arpGatewayOnlyarpServer set 1 $card $port

protocolServer get 1 $card $portprotocolServer config -enableRipService trueprotocolServer config -enablePingResponse falseprotocolServer set 1 $card $port

# Send to the hardwareixWritePortsToHardware plixCheckLinkState pl

# And start RIP on the portixStartRip pl

# Disable routeRange1 while rip server is runnung. # This is the same as removing the route range from router

ripServer select 1 $card $port

if [ripServer getRouter router01] { logMsg “Error getting router01”}if [ripInterfaceRouter getRouteRange routeRange01] { logMsg “Error getting routeRange01”}

# Disable the route rangeripRouteRange config -enableRouteRange false

if [ripInterfaceRouter setRouteRange routeRange01] {logMsg “Error setting routeRange01”

}if [ripServer write] {

logMsg “Error writing ripServer”}

# If you wanted to add a route range while rip server is running, # -Configure it disabled before starting rip server and then# enable it

SEE ALSO ripInterfaceRouter, ripRouteRange



NAME - rsvpDestinationRangersvpDestinationRange - configure an RSVP destination range

SYNOPSIS rsvpDestinationRange sub-command options

DESCRIPTION The rsvpDestinationRange command represents a simulated destination range. In addition to some identifying options, it holds three lists for the destination range:

• Sender ranges – a set of MPLS routers which are the tunnel start-points, constructed in the rsvpSenderRange command.

• ERO item – a set of addresses associated with the Explicit Route Option of RSVP messages, constructed in the rsvpEroItem com-mand. This option indicates the path through a set of MPLS routers that the tunnel is to take. This is used when the destination range is associated with an Ingress router.

• RRO item – a set of addresses associated with the Returned Route Option, constructed in the rsvpRroItem command. This option indi-cates the set of MPLS routers that were used in a tunnel’s creation. This is used when the destination range is associated with an Egress router.

Destination ranges defined in this command are added to an rsvpNeighborPair using the rsvpNeighborPair addDestinationRange command. Refer to “RSVP-TE” on page 3-27 for a discussion on RSVP testing with Ixia equipment. Refer to “rsvpDestinationRange” on page 5-74 for an overview of this command.

STANDARD OPTIONS

bandwidth The requested bandwidth for the tunnel, expressed in kbits per second. (default = 0)

behavior Indicates whether the destination range corresponds to an Ingress or Egress router. One of:

enableDestinationRange true / false

Enables the use of this destination range in the simulation. (default = false)

enableEro true / false Enables use of the ERO option in Ingress mode. (default = false)

enableResvConf true / false

Enables the generation of RESV Confirmation messages for received RESV messages which contain a RESV Confirmation Class object. (default = false)

enableSendRro true / false

When the destination range is used in Ingress mode, this indicates that a SEND RRO option is to be included in RSVP messages sent downstream. (default = false)

Option Value Usage

rsvpIngress 0 (default) Ingress Mode

rsvpEgress 1 Egress Mode


rsvpDestinationRangeA

eroMode Indicates whether the DUT’s address is to be prepended to the ERO list and whether it is a LOOSE or STRICT entry. One of:

fromIpAddress The IP address of the first destination router. (default = 0.0.0.0)

prefixLength If the DUT’s address is to be prepended to the ERO list, this indicates what prefix length is to be used for the entry. (default = 32)

rangeCount The number of destination routers. Each router’s address is one greater than the previous one’s. (default = 1)

refreshInterval When the destination range is rsvpEgress, this indicates the time, in seconds, between the simulated router’s message to the DUT. (default = 30000)

timeoutMultiplier The number of Hellos before a router is declared dead. (default = 3)

tunnelIdEnd The end of the range of tunnel IDs. (default = 0)

tunnelIdStart Sets the start of the range of Tunnel IDs to be used in simulations. (default = 0)

COMMANDS The rsvpDestinationRange command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

rsvpDestinationRange addEroItem

Adds the ERO item described in the rsvpEroItem command to the list of ERO items associated with the destination range. Specific errors are:

• The parameters in rsvpEroItem are invalid

rsvpDestinationRange addSenderRange senderRangeIdAdds the route range described in the rsvpSenderRange command to the list of sender ranges associated with the destination range. The sender range’s entry in the list is given an identifier of senderRangeId. Specific errors are:

• The parameters in rsvpSenderRange are invalid• A destination range with this senderRangeId exists already in the list

rsvpDestinationRange addRroItem

Adds the RRO item described in the rsvpRroItem command to the list of RRO items associated with the destination range. Specific errors are:

• The parameters in rsvpRroItem are invalid

rsvpDestinationRange cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rsvpDestinationRange command.

Option Value Usage

rsvpNone 0 do not prepend the DUT’s address

rsvpPrependLoose 1 (default) prepend the DUT’s address as a LOOSE address.

rsvpPrependStrict 2 prepend the DUT’s address as a STRICT address.



rsvpDestinationRange clearAllEro

Deletes all of the ERO items.

rsvpDestinationRange clearAllSender

Deletes all of the sender ranges.

rsvpDestinationRange clearAllRro

Deletes all of the user LSA groups.

rsvpDestinationRange config option valueModify the configuration options of the rsvpDestinationRange. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for rsvpDestinationRange.

rsvpDestinationRange delSenderRange senderRangeIdDeletes the sender range with an identifier of senderRangeId. Specific errors are:

• No destination range with this senderRangeId exists in the list

rsvpDestinationRange getFirstEroItem

Access the first ERO item in the list. The results may be accessed using the rsvpEroItem command. Specific errors are:

• rsvpServer select hasn’t been called• There are no ERO items in the list

rsvpDestinationRange getFirstSenderRange

Access the first sender range in the list. The results may be accessed using the rsvpSenderRange command. Specific errors are:

• There are no sender ranges in the list

rsvpDestinationRange getFirstRroItem

Access the first RRO item in the list. The results may be accessed using the rsvpRroItem command. Specific errors are:

• There are no RRO items in the list

rsvpDestinationRange getNextEroItem

Access the next ERO item in the list. The results may be accessed using the rsvpEroItem command. Specific errors are:

• rsvpDestinationRange getFirstEroItem hasn’t been called• There is no more ERO items in the list

rsvpDestinationRange getNextRroItem

Access the next RRO item in the list. The results may be accessed using the rsvpRroItem command. Specific errors are:

• rsvpDestinationRange getFirstRroItem hasn’t been called• There is no more RRO items in the list


rsvpDestinationRangeA

rsvpDestinationRange getNextSenderRange

Access the next sender range in the list. The results may be accessed using the rsvpSenderRange command. Specific errors are:

• rsvpDestinationRange getFirstSenderRange hasn’t been called• There is no more sender ranges in the list

rsvpDestinationRange getSenderRange senderRangeIdAccesses the sender range’s entry in the list with an identifier of senderRangeId. The sender range is accessed in the rsvpSenderRange command. Specific errors are:

• A destination range with this senderRangeId does not exist in the list

rsvpDestinationRange setDefault


rsvpDestinationRange setSenderRange senderRangeIdSets the values for the sender range’s entry in the list with an identifier of senderRangeId based on changes made through the rsvpSenderRange command. This command can be used to change a running configuration and must be fol-lowed by an rsvpServer write command in order to send these changes to the Pro-tocol Server. Specific errors are:

• A router with this senderRangeId does not exist in the list

EXAMPLES See examples under rsvpServer

SEE ALSO rsvpServer, rsvpNeighborPair, rsvpSenderRange, rsvpEroItem, rsvpRroItem


rsvpEroItem

NAME - rsvpEroItemrsvpEroItem – sets up the parameters associated with an RSVP ERO item.

SYNOPSIS rsvpEroItem sub-command options

DESCRIPTION The rsvpEroItem holds the information related to an ERO item used for in Ingress mode. ERO items are added into the rsvpDestinationRange list using the rsvpDestinationRange addEroItem command. Refer to “RSVP-TE” on page 3-27 for a discussion on RSVP testing with Ixia equipment. Refer to “rsvpEroI-tem” on page 5-78 for an overview of this command.

STANDARD OPTIONS

asNumber If the type field is rsvpAs, then this is the ERO value as an Autonomous System Number. (default = 0)

enableLooseFlag Indicates whether the ERO item is to be considered a LOOSE item or a STRICT item. (default = 0) One of:

ipAddress If the type field is rsvpEroIpv4, then this is the ERO value as an IP address prefix. (default = 0.0.0.0)

prefixLength If the type field is rsvpEroIpv4, then this defines the prefix length of the DUT IP address. (default = 0)

type The type of contents in the ERO entry. One of:

COMMANDS The rsvpEroItem command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

rsvpEroItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rsvpEroItem command.

rsvpEroItem config option valueModify the configuration options of the rsvpEroItem. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for rsvpEroItem.

Option Value Usage

rsvpPrependLoose 1 prepend the DUT’s address as a LOOSE address.

rsvpPrependStrict 2 prepend the DUT’s address as a STRICT address.

Option Value Usage

rsvpEroIpv4 0 (default) an IPv4 address

rsvpAs 1 an Autonomous System


rsvpEroItemA

rsvpEroItem setDefault



SEE ALSO rsvpServer, rsvpNeighborPair, rsvpDestinationRange, rsvpSenderRange, rsvpR-roItem


rsvpNeighborPair

NAME - rsvpNeighborPairrsvpNeighborPair - configure an RSVP neighbor pair

SYNOPSIS rsvpNeighborPair sub-command options

DESCRIPTION The rsvpNeighborPair command represents a pair of routers – the DUT and a directly connected simulated router. In addition to some identifying options, it holds a list for the neighbor pair:

• Destination ranges – routers which are the destination of con-structed MPLS tunnels, constructed in the rsvpDestinationRange command.

Neighbor pairs defined in this command are added to an rsvpServer using the rsvpServer addNeighborPair command. Refer to “RSVP-TE” on page 3-27 for a discussion on RSVP testing with Ixia equipment. Refer to “rsvpNeighborPair” on page 5-72 for an overview of this command.

STANDARD OPTIONS

dutAddresss The IP address of the Device Under Test. This is the RSVP router that the simulated router is directly connected to. (default = 0.0.0.0)

enableHello Enables the transmission of HELLO messages between the simulated router and the DUT. (default = 0)

enableNeighborPair Enables the use of this neighbor in the simulation. (default = 0)

helloInterval The interval, in seconds, between HELLO messages. (default = 5)

helloTimeoutMultiplier The number of Hellos sent without confirmation before the DUT is considered dead. (default = 3)

ipAddress The IP address of the simulated router. (default = 0.0.0.0)

labelSpaceEnd The last label to be used for RSVP tunnels. (default =1000)

labelSpaceStart The first label to be used for RSVP tunnels. (default = 16)

lsp_tunnel Read-only. When received MPLS labels are retreived from the Protocol Server for the simulated server, this represents the tunnel ID for the returned label.

numRxLabels Read-only. The number of RSVP labels received from a successful rsvpNeighborPair getLabels command.

rxLabel Read-only. This is the MPLS label associated with the tunnel ID in lsp_tunnel.


rsvpNeighborPairA

COMMANDS The rsvpNeighborPair command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

rsvpNeighborPair addDestinationRange destIdAdds the Destination Range described in the rsvpDestinationRange command to the list of Destination Ranges associated with the router. The Destination Range’s entry in the list is given an identifier of destId. Specific errors are:

• The parameters in rsvpDestinationRange are invalid• A router with this destId exists already in the list

rsvpNeighborPair cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rsvpNeighborPair command.

rsvpNeighborPair clearAllDestinationRange

Deletes all of the router Destination Ranges.

rsvpNeighborPair config option valueModify the configuration options of the rsvpNeighborPair. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for rsvpNeighborPair.

rsvpNeighborPair delDestinationRange destIdDeletes the router Destination Range with an identifier of destId. Specific errors are:

• No router with this destId exists in the list

rsvpNeighborPair getFirstDestinationRange

Access the first Destination Range in the list. The results may be accessed using the rsvpDestinationRange command. Specific errors are:

• rsvpServer select hasn’t been called• There are no Destination Ranges in the list

rsvpNeighborPair getDestinationRange destIdAccesses the Destination Range’s entry in the list with an identifier of destId. The Destination Range is accessed in the rsvpDestinationRange command. Specific errors are:

• A router with this destId does not exist in the list

rsvpNeighborPair getFirstLabel

This command must be preceded by use of the rsvpNeighborPair getLabels com-mand and followed by multiple uses of rsvpNeighborPair getNextLabel. This command fetches the first of the labels in the list into memory. The data associ-ated with the individual label may be read through the use of the lsp_tunnel and rxLabel options.


rsvpNeighborPair

rsvpNeighborPair getLabels

This command must be preceded by use of the rsvpNeighborPair requestRxLabels and followed by a call to rsvpNeighborPair getFirstLabel. This command determines whether the reading of labels from the Protocol Server has completed. This command should be called until it returns a ‘0’, or until some suitable period of time has elapsed. The number of labels is available in the numRxLabels option.

rsvpNeighborPair getNextDestinationRange

Access the next Destination Range in the list. The results may be accessed using the rsvpDestinationRange command. Specific errors are:

• rsvpNeighborPair getFirstDestinationRange hasn’t been called• There is no more Destination Ranges in the list

rsvpNeighborPair getNextLabel

This command must be preceded by use of the rsvpNeighborPair getFirstLabel command and repeated multiple times to obtain all of the learned LSAs. This command fetches the next of the labels in the list into memory. The data associ-ated with the individual label may be read through the use of the lsp_tunnel and rxLabel options.

rsvpNeighborPair requestRxLabels

Requests that the received RSVP labels associated with this neighbor pair be retrieved from the Protocol Server. This command must be followed by call to rsvpNeighborPair getLabels.

rsvpNeighborPair setDestinationRange destIdSets the values for the destination range’s entry in the list with an identifier of destId based on changes made through the rsvpDestinationRange command. This command can be used to change a running configuration and must be followed by an rsvpServer write command in order to send these changes to the Protocol Server. Specific errors are:


rsvpNeighborPair setDefault



SEE ALSO rsvpServer, rsvpDestinationRange, rsvpSenderRange, rsvpEroItem, rsvpRroItem


rsvpRroItemA

NAME - rsvpRroItemrsvpRroItem – sets up the parameters associated with an RSVP RRO item.

SYNOPSIS rsvpRroItem sub-command options

DESCRIPTION The rsvpRroItem holds the information related to an RRO item used for in Ingress mode. RRO items are added into the rsvpDestinationRange list using the rsvpDestinationRange addRroItem command. Refer to “RSVP-TE” on page 3-27 for a discussion on RSVP testing with Ixia equipment. Refer to “rsvpRroI-tem” on page 5-79 for an overview of this command.

STANDARD OPTIONS

cType If the type field is rsvpRroIpv4, then this is the C_Type of the included Label Object. (default = 1)

enableGlobalLabeltrue / false

If the type field is rsvpRroIpv4, then this indicates that the label will be understood if received on any interface. (default = false)

enableProtectionAvailable true / false

If the type field is rsvpRroIpv4, then this indicates that local protection is made available for the downstream link. (default = false)

enableProtectionInUsetrue / false

If the type field is rsvpRroIpv4, then this indicates that the local protection is being used currently to maintain this tunnel. (default = false)

ipAddress If the type field is rsvpRroIpv4, then this is the RRO value as an IPv4 address. (default = 0.0.0.0)

label If the type field is rsvpLabel, then this is the RRO value as an assigned label. (default = 0)

type The type of contents in the ERO entry. One of:

COMMANDS The rsvpRroItem command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

rsvpRroItem cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rsvpRroItem command.

rsvpRroItem config option valueModify the configuration options of the rsvpRroItem. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for rsvpRroItem.

Option Value Usage

rsvpRroIpv4 0 (default) an IPv4 address

rsvpLabel 1 an MPLS label


rsvpRroItem

rsvpRroItem setDefault



SEE ALSO rsvpServer, rsvpNeighborPair, rsvpDestinationRange, rsvpSenderRange, rsvpEroItem


rsvpSenderRangeA

NAME - rsvpSenderRangersvpSenderRange – sets up the parameters associated with an RSVP sender range.

SYNOPSIS rsvpSenderRange sub-command options

DESCRIPTION The rsvpSenderRange command holds the information related to the originating routers for the MPLS tunnels being simulated in Ingress cases. Sender ranges are added into the rsvpDestinationRanges list using the rsvpDestinationRanges addSenderRange command. Refer to “RSVP-TE” on page 3-27 for a discussion on RSVP testing with Ixia equipment. Refer to “rsvpSenderRange” on page 5-77 for an overview of this command.

STANDARD OPTIONS

bandwidth The bandwidth requested for the connection, expressed in kbits/sec. (default = 0)

enableAutoSessionName true / false

Enables the Session Name to be generated automatically. (default = true)

enableLabelRecordingDesired true / false

This indicates that label information is to be included when doing a record route operation. (default = false)

enableLocalProtectionDesired true / false

This permits transit routers to use a local traffic rerouting repair mechanism, in the event of a fault on an adjacent downstream link or node. This may result in a violation of the explicit route object. (default = true)

enableRaSessionAttribute true / false

Enables the use of resource affinities as set by excludeAny, includeAny, and includeAll. (default = false)

enableSenderRangeDesired true / false

Enables the sender range entry. (default = false)

enableSeStyleDesiredDesired true / false

This indicates that the tunnel ingress node may reroute this tunnel without tearing it down. A tunnel egress node should use the SE Style when responding with an RESV message. (default = false)

excludeAny Represents a set of attribute filters associated with a tunnel, any of which renders a link unacceptable. (default = 00 00 00 00)

fromIpAddress The IP address of the first sender router. (default = 0.0.0.0)

holdingPriority This is the session priority with respect to holding resources, such as keeping a session during preemption. The valid range is from 0 to 7. The highest priority is indicated by 0. (default = 7)

includeAll Represents a set of attribute filters associated with a tunnel, all of which must be present for a link to be acceptable (with respect to this test). When all bits are set to 0 (null set), it automatically passes. (default = 00 00 00 00)


rsvpSenderRange

includeAny Represents a set of attribute filters associated with a tunnel, any of which makes a link acceptable (with respect to this test). When all bits are set to 0 (null set), it automatically passes. (default = 00 00 00 00)

lspIdEnd The end of the range of LSP IDs. (default = 0)

lspIdStart The start of the range of LSP IDs to be generated. (default = 0)

rangeCount The number of routers in the sender range. Each sender router has an IP address one higher than its predecessor. (default = 1)

refreshInterval The value of the refresh interval, in milliseconds. (default = 30000)

sessionName If enableAutoSessionName is not set, this is the name assigned to this Session. (default = ““)

setupPriority This is the session priority with respect to taking resources, such as preempting another session. The valid range is from 0 to 7. The highest priority is indicated by 0. (default = 7)

timeoutMultiplier The number of Hellos before a neighbor is declared dead. (default = 3)

COMMANDS The rsvpSenderRange command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

rsvpSenderRange cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rsvpSenderRange command.

rsvpSenderRange config option valueModify the configuration options of the rsvpSenderRange. If no option is speci-fied, returns a list describing all of the available options (see STANDARD OPTIONS) for rsvpSenderRange.

rsvpSenderRange setDefault



SEE ALSO rsvpServer, rsvpNeighborPair, rsvpDestinationRange, rsvpEroItem, rsvpRroItem


rsvpServerA

NAME - rsvpServerrsvpServer - access the RSVP component of the Protocol Server for a particular port.

SYNOPSIS rsvpServer sub-command options

DESCRIPTION The rsvpServer command is necessary in order to access the RSVP Protocol Server for a particular port. The select sub-command must be used before all other RSVP commands. Refer to “RSVP-TE” on page 3-27 for a discussion on RSVP testing with Ixia equipment. Refer to “rsvpServer” on page 5-71 for an overview of this command.

STANDARD OPTIONS

None

COMMANDS The rsvpServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

rsvpServer addNeighborPair NeighborPairIdAdds the RSVP neighbor pair described in the rsvpNeighborPair command to the list of neighbor pairs associated with the port. The neighbor pair’s entry in the list is given an identifier of NeighborPairId. Specific errors are:

• rsvpServer select hasn’t been called• The neighbor pair parameters in rsvpNeighborPair are invalid• A neighbor pair with this NeighborPairId exists already in the list

rsvpServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the rsvpServer command.

rsvpServer clearAllNeighborPair

Deletes all the RSVP neighbor pairs in the list. Specific errors are: • rsvpServer select hasn’t been called

rsvpServer config option valueModify the configuration options of the rsvpServer. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for rsvpServer.

rsvpServer delNeighborPair NeighborPairIdDeletes the RSVP neighbor pair described that has an identifier of Neighbor-PairId. Specific errors are:

• rsvpServer select hasn’t been called• There is no neighbor pair with this NeighborPairId in the list


rsvpServer

rsvpServer getFirstNeighborPair

Access the first RSVP neighbor pair in the list. The results may be accessed using the rsvpNeighborPair command. Specific errors are:

• rsvpServer select hasn’t been called• There are no neighbor pairs in the list

rsvpServer getNextNeighborPair

Access the next RSVP neighbor pair in the list. The results may be accessed using the rsvpNeighborPair command. Specific errors are:

• rsvpServer select hasn’t been called• rsvpServer getFirstNeighborPair hasn’t been called• There are no more neighbor pairs in the list

rsvpServer getNeighborPair NeighborPairIdAccess the RSVP neighbor pair with an identifier of NeighborPairId. The results may be accessed using the rsvpNeighborPair command. Specific errors are:

• rsvpServer select hasn’t been called• There is no neighbor pair with this NeighborPairId in the list

rsvpServer select chasID cardID portIDAccesses the RSVP component of the Protocol server for the indicated port. Spe-cific errors are:

• No connection to the chassis• The RSVP protocol package has not been installed• Invalid port specified

rsvpServer NeighborPair NeighborPairIdSets the values for the neighbor pair’s entry in the list with an identifier of NeighborPairId based on changes made through the rsvpNeighborPair com-mand. This command should be used to change a running configuration and must be followed by an rsvpServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A router with this NeighborPairId does not exist in the list

rsvpServer setNeighborPair NeighborPairIdSets the values for the neighbor pair’s entry in the list with an identifier of NeighborPairId based on changes made through the rsvpNeighborPair com-mand. This command should be used to change a running configuration and must be followed by an rsvpServer write command in order to send these changes to the Protocol Server. Specific errors are:

• A neighbor with this rsvpNeighborPair does not exist in the list

rsvpServer write

Writes or commits the changes in IxHAL to hardware for the currently selected chassis, card and port. Before using this command, use the rsvpServer select command to select the port.


rsvpServerA


# Define parameters used by rsvp routerset host rubyif [ixInitialize $host] { logMsg “Error in connecting to hostName” return 1}

# Port is card 2, port 1set ch [chassis cget -id]set ca 9set po 1set pl [list [list $ch $ca $po]]set myMac {00 0a de 01 01 01}set router 101.101.9.2set neighbor 101.101.9.1

# Set up IP address table for others who ARP to usipAddressTableItem setDefault ipAddressTableItem config -numAddresses 1ipAddressTableItem config -mappingOption oneIpToOneMACipAddressTableItem config -overrideDefaultGateway falseipAddressTableItem config -fromIpAddress $routeripAddressTableItem config -fromMacAddress $myMacipAddressTable addItemipAddressTable set $ch $ca $po

# Select port to operateif [rsvpServer select $ch $ca $po] { logMsg “Error in selecting the port $ch $ca $po”}

# Clear all neighborPairsrsvpServer clearAllNeighborPair

# Configure the senderRange for first destinationRangersvpSenderRange setDefault rsvpSenderRange config -enableSenderRange truersvpSenderRange config -fromIpAddress {1.1.1.1}rsvpSenderRange config -rangeCount 1rsvpSenderRange config -lspIdStart 1rsvpSenderRange config -lspIdEnd 160

# Add senderRange to destinationRangeif [rsvpDestinationRange addSenderRange senderRange1] { logMsg “Error adding senderRange senderrange1”}

# Configure destinationRangersvpDestinationRange setDefault rsvpDestinationRange config -enableDestinationRange truersvpDestinationRange config -behavior rsvpIngressrsvpDestinationRange config -fromIpAddress {2.2.2.2}rsvpDestinationRange config -rangeCount 1rsvpDestinationRange config -tunnelIdStart 1rsvpDestinationRange config -tunnelIdEnd 1

# Add destinatioanRange to the neighborPairif [rsvpNeighborPair addDestinationRange destinationRange1] { logMsg “Error adding destinationRange destinationRange1]}


rsvpServer

# Configure the neighborPairrsvpNeighborPair setDefault rsvpNeighborPair config -enableNeighborPair truersvpNeighborPair config -ipAddress {1.1.1.1}rsvpNeighborPair config -dutAddress {2.2.2.2}

# Add the neighborPair to the rsvp serverif [rsvpServer addNeighborPair neighborPair1] { logMsg “Error in adding neighborPair to the server”}

# Enable RSVP operationprotocolServer config -enableRsvpService trueprotocolServer set $ch $ca $po


# And start rsvp on the portixStartRsvp pl

# Disable destinationRange while rsvp server is runnung. # This is the same as removing the destination from router

rsvpServer select $ch $ca $po

if [rsvpServer getNeighborPair neighborPair1] { logMsg “Error getting router1”}

if [rsvpNeighborPair getDestinationRange destinationRange1] { logMsg “Error getting routeRange1”}

# Disable the route range (You can also change other configuration if you want)rsvpDestinationRange config -enableDestinationRange false

if [rsvpNeighborPair setDestinationRange destinationRange1] {logMsg “Error setting routeRange1”

}

if [rsvpServer write] {logMsg “Error writing rsvpServer”

}

# Stop the server at the endixStopRsvp pl

SEE ALSO rsvpNeighborPair, rsvpDestinationRange, rsvpSenderRange, rsvpEroItem, rsvpRroItem


sessionA

NAME - sessionsession - manage a multiuser session

SYNOPSIS session sub-command options

DESCRIPTION The session command is used to login and logout of this Tcl session. A user is not required to login to configure ports; however in order to take ownership of a group of ports in a multiuser environment, the user must log in. Session login is valid for the entire duration of a Tcl window, regardless of how many times a package require IxTclHal or cleanUp is initiated or until the user logs out. Log-ging in as a different user name is the same as logging out and logging in again with a different login name.

STANDARD OPTIONS

userName Read-only. User name for this session.

COMMANDS The session command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

session config option valueModify the session configuration options of the port. If no option is specified, returns a list describing all of the available session options (see STANDARD OPTIONS) for port. (Since there are no writable options, this command is not currently useful).

session cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the session command.

session login userNameInitiate a login to a new multiuser session. If already logged in as a different user-Name, log out existing user and log in new userName. Specific errors are:

• No connection to a chassis• UserName is null

session logout

Logs out current user.


# Login for georgesession login george

# See who’s logged inset userName [session cget -userName]ixPuts “$userName is currently logged in”


session

# Logoutsession logout

# And check againset userName [session cget -userName]ixPuts “$userName is currently logged in”

SEE ALSO ixLogin, ixLogout


sonetA

NAME - sonetsonet - configure the sonet properties of a POS port of a card on a chassis.

SYNOPSIS sonet sub-command options

DESCRIPTION The sonet command is used to configure the sonet properties of a POS port of a card on a chassis. Note: sonet error insertion is now handled by the sonetError command; sonet commands related to error insertion are now deprecated.

STANDARD OPTIONS

apsType Sets the Automatic Protection Switching (APS) bytes. Options include:

C2byteExpected Received path signal label. (default = CF)

C2byteTransmit Register-programmable path signal label. (default = CF)

customK1K2 enable/disable

Enables or disables custom K1K2. (default = disable)

dataScrambling enable/disable

Enables or disables data scrambling in the sonet framer. (default = enable)

header Enable sonet header type. Options include:

interfaceType Sets the type/speed of the sonet interface. Options include:

Option Value Usage

linearAps 0 (default) The K1 and K2 Automatic Protection Switching (APS) bytes bit definitions represent a lin-ear topology.

ringAps 1 The K1 and K2 Automatic Protection Switching (APS) bytes bit definitions represent a ring topology.

Option Value Usage

sonetHdlcPppIp 0 (default)

sonetCiscoHdlc 1

sonetOther 2

sonetFrameRelay1490 3

sonetFrameRelay2427 3

sonetFrameRelayCisco 4

sonetSrp 5

sonetCiscoHdlcIpv6 6

sonetHdlcPppIso 7

Option Value Usage

oc3 0

oc12 1 (default)


sonet

k1NewState Enables the K1 byte code value to be sent in the Sonet frame. (It is used by sonnet APS (automatic protection switching) to implement a bit-oriented protocol for critical switching operations). (default = 0)

k2NewState Enables the K2 byte code value as in k1NewState. (default = 0)

lineErrorHandling enable/disable

Enables/disables line error handling on the sonet interface. (default = disable)

lineScrambling enable/disable

Enables or disables line scrambling in the sonet framer. Applies only to the POS/sonet interface ports. (default = enable)

operation Sets up the sonet interface/operation either as normal mode or loopback mode. Options include:

pathErrorHandling enable/disable

Enables or disables path error handling on the sonet interface. (default = disable)

rxCrc Sets the receive CRC mode. Options include:

txCrc Sets the transmit CRC mode. Options include:

useRecoveredClock true/false

Set the sonet framer to use the recovered clock. (default = true)

oc48 2

stm1c 3

stm4c 4

stm16c 5

oc192 6

stm64c 7

ethOverSonet 8

ethOverSdh 9

Option Value Usage

Option Value Usage

sonetNormal 0 (default)

sonetLoopback 1

sonetLineLoopback 2

sonetFramerParallelDiagnosticLoopback

3

sonetFramerDiagnosticLoopback 4

Option Value Usage

sonetCrc16 0

sonetCrc32 1 (default)

Option Value Usage

sonetCrc16 0

sonetCrc32 1 (default)


sonetA


B1 enable/disable Enables or disables insertion of B1 errors; only applies if insertBipErrors is set to true. (default = disable)



errorDuration The amount of time, expressed in seconds, between periodic error insertions as indicated by the periodB1, periodicB2, periodicB3, and periodicLossOfFrame.

insertBipErrors true/false

Enables or disables inserting of Bip errors; see B1/B2/B3. (default = false)

lossOfFrame true/false Force loss of frame condition. (default = false)

lossOfSignal true/false Force loss of signal condition. (default = false)

periodicB1 enable/disable

Enables or disables the period insertion of B1 errors; only applies if insertBipErrors is set to true. The frequency with which the errors are inserted is controlled by the errorDuration option. (default = disable)





periodicLossOfFrame enable/disable

Force a periodic loss of frame condition. The frequency with which the errors are inserted is controlled by the errorDuration option. (default = false)

lossOfSignal enable/disable

Force a periodic loss of signal condition. The frequency with which the errors are inserted is controlled by the errorDuration option. (default = false)

COMMANDS The sonet command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

sonet cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the sonet command.

sonet config option valueModify the configuration options of the port. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for port. If option is specified with no value, then the commands returns a list of values available for this option.


sonet

sonet get chasID cardID portIDGets the current configuration of the port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling sonet cget option value to get the value of the configuration option. Specific errors are:


sonet set chasID cardID portIDSets the configuration of the port in IxTclHAL with id portID on card cardID, chassis chasID by reading the configuration option values set by the sonet config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• The port is not a Packet over Sonet port or 10Gigabit WAN.

sonet setDefault




# Assuming that an OC48 POS card is in slot 8set card 8set portList [list [list $chas $card 1]]

# Get the type of card and check if it’s the correct typeset ifType [card getInterface $chas $card]if {$ifType != $::interfaceOc48} \{ ixPuts “Card $card is not an OC48c POS card”} \else \{ # Reset to the defaults and then set several values sonet setDefault sonet config -interfaceType oc48 sonet config -header sonetCiscoHdlc sonet config -lineErrorHandling enable sonet config -rxCrc sonetCrc16 sonet config -txCrc sonetCrc16

# Send to ixTclHal and thence to the hardware sonet set $chas $card 1 ixWriteConfigToHardware portList}

SEE ALSO card, port, sonetError


sonetErrorA

NAME - sonetErrorsonetError - configure the sonet error generation of a POS port of a card on a chassis.

SYNOPSIS sonetError sub-command options

DESCRIPTION The sonetError command is used to configure the sonet error generation proper-ties of a POS port of a card on a chassis.

STANDARD OPTIONS

consecutiveErrors The number of consecutive error frames to insert when an error is inserted either periodically, continuously or only once. (default = 1)

errorPeriod If insertionMode is set to sonetPeriodic, then this is the period of time or number of frames to insert errors over, depending on the setting of errorUnits. A value of 1 will always be used for OC12/OC3 ports. (default = 1)

errorUnits If insertionMode is set to sonetPeriodic, then this determines whether errorPeriod refers to time (expressed in seconds) or frames. OC12/OC3 cards may only use units of seconds. One of:

insertionMode The periodicity of error insertion. One of:

sonetErrorType Read-only. When a error configuration is read back with sonetError getError, this reflects the sonet error type. One of:

Option Value Notes

sonetFrames 0 (default) errorPeriod expressed in number of frames

sonetSeconds 1 errorPeriod expressed in number of seconds

Option Value Notes

sonetContinuous 0 Errors are inserted continuously

sonetPeriodic 1 Errors are inserted periodically as determined by errorPeriod and errorUnits

sonetOff 2 (default) Errors are not inserted

Option Value Usage

sonetLofError 1 Loss of Frame

sonetBip1Error 2 BIP 1



sonetLineAis 5 Line AIS

sonetLineRei 6 Line REI

sonetLineRdi 7 Line RDI

sonetPathAis 9 Path AIS

sonetPathRei 10 Path REI


sonetError

COMMANDS The sonet command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

sonetError cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the sonet command.

sonetError config option valueModify the configuration options of the port. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for port.

sonetError get chasID cardID portIDGets the current sonetError configuration for all of the sonet error types for the port indicated from its hardware. Call this command before calling sonet cget option value to get the value of the configuration option. Specific errors are:


sonetError getError sonetErrorTypeRetrieves the values of the attributes (insertionMode, consecutiveErrors, error-Period, and errorUnits) associated with the sonetErrorType. See the description of sonetErrorType above for a list of the possible values of sonetErrorType. The sonetError get command must be used before getError.

sonetError insertError sonetErrorType chasID cardID portIDInserts a single instance of the error defined by sonetErrorType and in the stan-dard options into the sonet stream for the indicated port.

sonetError set chasID cardID portIDSets the configuration of the port in IxTclHAL with id portID on card cardID, chassis chasID by reading the configuration option values set by the sonet config option value command. Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The configured parameters are not valid for this port• The port is not a Packet over Sonet port or 10Gigabit WAN.

sonetError setDefault

Sets default values for all configuration options and resets all hardware configu-ration as well.

sonetError setError sonetErrorTypeSets the attributes (insertionMode, consecutiveErrors, errorPeriod, and errorUnits) associated with the sonetErrorType. See the description of sonetEr-rorType above for a list of the possible values of sonetErrorType. The sonetError set command should be used after this command to write the values to the hard-ware.


sonetErrorA

sonetError start chasID cardID portIDStarts sonet error insertion on the selected port.Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The port is not a Packet over Sonet port or 10Gigabit WAN.

sonetError stop chasID cardID portIDStops sonet error insertion on the selected port.Specific errors are:

• No connection to a chassis• Invalid port number• The port is being used by another user• The port is not a Packet over Sonet port or 10Gigabit WAN.


proc printState {} \{ for {set errType $::sonetLofError} {$errType < $::sonetPathRei} {incr errType} { sonetError getError $errType

ixPuts ““ ixPuts -nonewline “ insertionMode: “ ixPuts -nonewline [sonetError cget -insertionMode] ixPuts -nonewline “ errorPeriod: “ ixPuts -nonewline [sonetError cget -errorPeriod] ixPuts -nonewline “ errorUnits: “ ixPuts -nonewline [sonetError cget -errorUnits] ixPuts -nonewline “ consecutiveErrors: “ ixPuts [sonetError cget -consecutiveErrors]”}}


# Assuming that an OC48 POS card is in slot 8set card 8set portList [list [list $chas $card 1]]

# Get the type of card and check if it’s the correct typeset ifType [card getInterface $chas $card]if {$ifType != $::interfaceOc48} \{ ixPuts “Card $card is not an OC48c POS card”} \else \{ sonetError setDefault

ixPuts ““ ixPuts “Initial State:” printState

sonetError config -insertionMode sonetContinuous sonetError config -consecutiveErrors 5 sonetError setError sonetLofError


sonetError

sonetError config -insertionMode sonetPeriodic sonetError config -errorUnits sonetSeconds sonetError config -errorPeriod 10 sonetError config -consecutiveErrors 20 sonetError setError sonetBip1Error

sonetError set $chas $card 1 ixWritePortsToHardware portList

sonetError get $chas $card 1 ixPuts “After changes:” printState

sonetError start $chas $card 1 after 1000 sonetError stop $chas $card 1

sonetError setDefault sonetError config -consecutiveErrors 4 sonetError insertError sonetLineAis $chas $card 1}

SEE ALSO card, port, sonet


statA

NAME - statstat - gets the statistics on a port of a card on a chassis.

SYNOPSIS stat sub-command options

DESCRIPTION The stat command is used to get statistics. Statistics may be gathered in several ways. All statistics may be obtained through the use of the stat get allStats <chassis> <card> <port> followed by calls to get the data using stat cget -statName. All rate statistics may be obtained through the use of the stat getRate allStats <chassis> <card> <port> followed by calls to get the data using stat cget -statName. An individual statistic may be collected through the use of the stat get statName <chassis> <card> <port> followed by stat cget -statName. Note that the statName is formed from the standard option name by prepending stat to the name and capitalizing the first letter of the option. (E.g. for the option framesSent, the statName is statFramesSent.) The statistic is also available through stat cget -counterVal and the corresponding rate is available through stat cget -counterRate. No call to stat getRate is needed to get the rate.Values are available through the STANDARD OPTIONS following the stat cget call. When using stat cget -statName, only those statistics valid for that type of port are returned; all others will return an error (see the enableValidStats option). Refer to Available Statistics for a list of which statistics are available for particu-lar card modules and under particular circumstances.

STANDARD OPTIONS

Standard Options controlling statistics modes and operation

enableArpStats true/false

Enables the collection of the protocol server’s ARP statistics. enableProtocolServerStats must also be set to true. (default = true)

enableBgpStats true/false

Enables the collection of the protocol server’s BGP4 statistics. enableProtocolServerStats must also be set to true. (default = false)

enableIcmpStats true/false

Enables the collection of the protocol server’s ICMP statistics. enableProtocolServerStats must also be set to true. (default = true)

enableIsisStats true/false

Enables the collection of the protocol server’s ISIS statistics. enableProtocolServerStats must also be set to true. (default = false)

enableOspfStats true/false

Enables the collection of the protocol server’s OSPF statistics. enableProtocolServerStats must also be set to true. (default = false)

enablePosExtendedStats true/false

Enables the collection of extended PoS extended statistics, for POS cards only. (default = true)

enableProtocolServerStats true/false

Master enable for the protocol server. This must be set to true for ARP, BGP and ICMP statistics. (default = true)


stat

enableRsvpStats true/false

Enables the collection of the protocol server’s RSVP statistics. enableProtocolServerStats must also be set to true. (default = false)

enableTemperatureSensorStats true/false

Enables the collection of statistics from temperature sensors. (default = true)

enableUsbExtendedStats true/false

Enables the collection of extended USB extended statistics, for USB cards only. (default = true)

enableValidStatstrue / false

If set, then stat cget -statName calls for statistics invalid for the port’s type will return an error. If unset, then all stat cget -statName will return without error, but the invalid statistics will have default values. (default = 0)

mode Sets the mode of the statistic counters. The following modes can be read:

Standard Options used to retrieve statistics

alignmentErrors Read-only. 64-bit value. Number of frames received with alignment errors on a 10/100 port.

backgroundTemperature

Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the Background chip.

bertAvailableSeconds Read-only. 64-bit value. For BERT - the number of seconds which have occurred during Available Periods.

bertBackgroundBlockErrorRatio

Read-only. For BERT – the ratio of Background Block Errors (BBEs) to the total number of blocks.

bertBackgroundBlockErrors

Read-only. 64-bit value. For BERT - the number of errored blocks not occurring as part of a Severely Errored Second.

bertBitErrorRatio Read-only. For BERT – the ratio of the number of errored bits compared to the total number of bits transmitted.

bertBitErrorsReceived Read-only. 64-bit value. For BERT - the total number of bit errors received.

bertBitErrorsSent Read-only. 64-bit value. For BERT - the total number of bit errors sent.

bertBitsReceived Read-only. 64-bit value. For BERT - the total number of bits received.

bertBitsSent Read-only. 64-bit value. For BERT - the total number of bits sent.

Option Value Usage

statNormal 0 (default)

statQos 1 Reuses 8 hardware counters to count QoS packets

statStreamTrigger 2 Reuses two hardware counters: User-Defined Statistics Counters 5 and 6.

statModeChecksumErrors 3 Reuses 6 hardware counters to count IP, TCP, UDP checksum errors.

statModeDataIntegrity 4 Reuses 2 hardware counters.


statA

bertBlockErrorState Read-only. For BERT - whether the link is in an available or unavailable state. One of:

bertElapsedTestTime Read-only. 64-bit value. For BERT - the elapsed test time, expressed in seconds in the APIs.

bertErroredBlocks Read-only. 64-bit value. For BERT - the number of blocks containing at least one errored second.

bertErrorFreeSeconds

Read-only. 64-bit value. For BERT - the number of seconds with no errored blocks or defects.

bertErroredSecondRatio

Read-only. For BERT - (ESR); the ratio of Errored Seconds (ES) to the total sec-onds.

bertErroredSeconds Read-only. 64-bit value. For BERT - the number of seconds containing at least one errored block or a defect.

bertLastServiceDisruptionTime

Read-only. 64-bit value. For BERT - a service disruption is the period of time during which the service is unavailable while switching rings. The SONET spec calls for this to be less than 50 ms. This value is the length of the last service disruption that occurred, expressed in milliseconds

bertMaxServiceDisruptionTime

Read-only. 64-bit value. For BERT - the longest service disruption that occurred, expressed in milliseconds.

bertMinServiceDisruptionTime

Read-only. 64-bit value. For BERT - the shortest service disruption that occurred, expressed in milliseconds.

bertMismatchedOnesRatio

Read-only. The number of expected ones that where received as zeroes.

bertMismatchedZerosRatio

Read-only. The ratio of mismatched ones to the total number of bits.

bertNumberMismatchedOnes

Read-only. 64-bit value. The number of expected zeroes that where received as ones.

bertNumberMismatchedZeros

Read-only. 64-bit value. The ratio of mismatched zeroes to the total number of bits.

bertSeverelyErroredSecondRatio

Read-only. For BERT - (SESR); the ratio of Severely Errored Seconds (SESs) to the total seconds.

bertServiceDisruptionCumulative

Read-only. 64-bit value. For BERT - the total service disruption time encountered, expressed in milliseconds.

Option Value Usage

statBertUnavailablePeriod 0 Link is currently unavailable.

statBertAvailablePeriod 1 Link is currently available.


stat

bertStatus Read-only. 64-bit value. For BERT - the status of the receive connection. One of:.

bertUnavailableSeconds

Read-only. 64-bit value. For BERT - the number of seconds which have occurred during Unavailable Periods.

bgpTotalSessions Read-only. 64-bit value. For BGP4 - the number of BGP4 sessions that were config-ured.

bgpTotalSessionsEstablished

Read-only. 64-bit value. (For BGP4) The number of configured BGP4 sessions that established adjacencies.

bytesReceived Read-only. 64-bit value. Number of bytes received.

bytesSent Read-only. 64-bit value. Number of bytes transmitted.

captureFilter Read-only. 64-bit value. Number of frames received meeting the capture filter criteria set up using filter command. This counter is available when stat mode is set to statNormal.

Option Value Pattern Locked

statBertNotLocked 0 None.

statBertLockedOnInvertedAllZero 1 Inverted all zeroes.

statBertLockedOnInvertedAlternatingOneZero

2 Inverted alternating one-zero.

statBertLockedOnInvertedUserDefinedPattern

3 Inverted user defined pattern.

statBertLockedOnInverted2to31powerLinearFeedbackShiftReg

4 Inverted 2**31.


5 Inverted 2**11.


6 Inverted 2**15.


7 Inverted 2**20.


8 Inverted 2**23.

statBertLockedOnAllZero 9 All zeroes.

statBertLockedOnAlternatingAllZero 10 Alternating one-zero.

statBertLockedOnAlternatingOneZero 11 User defined pattern.

statBertLockedOn2to31powerLinearFeedbackShiftReg

12 2**31.


13 2**11.


14 2**15.


15 2**20.


16 2**23.


statA

captureState Read-only. Reflects the current state of capture. The following states can be read:

captureTemperature Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the Capture chip.

captureTrigger Read-only. 64-bit value. Number of frames received meeting the capture trigger criteria set up using filter command. This counter is available when stat mode is set to statNormal.

collisionFrames Read-only. 64-bit value. Number of frames received with collisions.

collisions Read-only. 64-bit value. Number of collisions.

counterRate Read-only. 64-bit value. The rate of the value of the statistic counter.

counterVal Read-only. 64-bit value. The value of the statistic counter.

dataIntegrityErrors Read-only. 64-bit value. Number of frames that have data integrity error.

dataIntegrityFrames Read-only. 64-bit value. Number of frames that match data integrity signiture.

dmaTemperature Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the DMA chip.

dribbleErrors Read-only. 64-bit value. Number of frames received with dribble errors on a 10/100 port.

duplexMode Read-only. The duplex mode configured for the port retrieved by calling the command stat get statAllStats.

excessiveCollisionFrames

Read-only. 64-bit value. Number of frames received with excessive collisions.

fcsErrors Read-only. 64-bit value. Number of frames received with FCS errors.

flowControlFrames Read-only. 64-bit value. Number of flow control frames received.

fobBoardTemperature Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Stats. The tempera-ture of the board of the Fiber optic module.

fobDeviceInternalTemperature

Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Stats. The tempera-ture of the FPGA on the Fiber optic module.

fobPort1FpgaTemperature

Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Stats. The tempera-ture next to port 1 on the Fiber optic module.

fobPort2FpgaTemperature

Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Stats. The tempera-ture next to port 2 on the Fiber optic module.

fragments Read-only. 64-bit value. Number of fragmented frames received.

Option Value Usage

statIdle 0 capture stopped

statActive 1 port currently capturing


stat

framerAbort Read-only. 64-bit value.

framerFCSErrors Read-only. 64-bit value.

framerMaxLength Read-only. 64-bit value.

framerMinLength Read-only. 64-bit value.

framesReceived Read-only. 64-bit value. Number of frames received.

framesSent Read-only. 64-bit value. Number of frames transmitted.

frontEndTemperature Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the Front End chip.

inputSignalStrength Read-only. Monitors receive optical input power.

ipChecksumErrors Read-only. 64-bit value. Number of frames transmitted.

ipPackets Read-only. 64-bit value. Number of frames transmitted.

isisSessionConfiguredL1

Read-only. 64-bit value. The total number of level 1 configured sessions.

isisSessionConfiguredL2

Read-only. 64-bit value. The total number of level 2 configured sessions.

isisSessionsUpL1 Read-only. 64-bit value. The total number of level 1 configured sessions that are fully up.

isisSessionsUpL2 Read-only. 64-bit value. The total number of level 2 configured sessions that are fully up.

lateCollisions Read-only. 64-bit value. Number of frames received with late collisions.

latencyTemperature Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the Latency chip.

lineAis Read-only. A flag indicating whether any Line Alarm Indication Signal have been received on an OC port for Packet over Sonet interfaces. Contains a value after the class method stat get statAllStats is used:

0 – no errors1 – alarm2 – not applicable

lineAisAlarmSecs Read-only. 64-bit value. A count of the seconds during which (at any point during the second) at least one Line layer AIS defect was present.

lineBip Read-only. 64-bit value. Number of Line Bit Interleaved Parity errors received on OC ports for POS interfaces.

lineBipErroredSecs Read-only. 64-bit value. A count of the seconds during which (at any point during the second) at least one Line layer BIP was detected.


statA

lineRdi Read-only. 64-bit value. A flag indicating whether any Line Remote Defect Indicators (former FERF – Far End Receive Failure) have been received on an OC ports for Packet over Sonet interfaces. Contains value after the class method stat get statAllStats is used:


lineRdiUnavailableSecs Read-only. 64-bit value. A count of the seconds during which the line is considered unavailable at the far end.

lineRei Read-only. 64-bit value. Number of Line Remote Error Indications (former FEBE – Far End Block Error) received on OC ports for Packet over Sonet interfaces.

lineReiErroredSecs Read-only. 64-bit value. A count of the seconds during which at least one line BIP error was reported by the far end.

lineSpeed Read-only. The speed configured for the port.

link Read-only. The state of the link. The following states can be read from the port:

Option Value Usage

linkDown 0 The link on the port is down. This may be because there is no cable connected to the port or the link on the destination port may be down. The LED on the card is off when the link is down. (default)

linkUp 1 the link is up indicated by green LED on the card.

linkLoopback 2 the port has been set to loopback mode. The LED on the card is off in this mode.

miiWrite 3 the link goes into this state when the configuration of 10/100 port is being written to hardware (applicable to 10/100 only)

restartAuto 4 restarts the auto-negotiation process

autoNegotiating 5 the link is in currently executing the auto-negotiation process

miiFail 6 failed to write into memory for 10/100 ports (applica-ble to 10/100 only)

noTransceiver 7 No external transceiver detected on Ixia Mii or Rmii port.

invalidAddress 8 No PHY detected at the selected address.

pppInit 19 PPP link negotiation state. This is an intermediate state and should be used for informational purposes only. Initialization state at the start of the negotiation process.

readLinkPartner 9 Auto negotiation state in negotiation process. This is an intermediate state and should be used for infor-mational purposes only.

noLinkPartner 10 Auto negotiation state in negotiation process. No link partner was found. This is an intermediate state and should be used for informational purposes only


stat

restartAutoEnd 11 Auto negotiation state in negotiation process. This is an intermediate state and should be used for infor-mational purposes only.

fpgaDownloadFail 12 Fpga download failure. Port will not be usable.

noGbicModule 13 No GBIC module detected on Ixia GBic port.

fifoReset 14 State in board initialization process. This is an inter-mediate state and should be used for informational purposes only.

fifoResetComplete 15 State in board initialization process. This is an inter-mediate state and should be used for informational purposes only.

pppOff 16 PPP is disabled. PPP control packets will be ignored; PPP link negotiation will not be performed. Does not mean the link is unusable; it may, for instance, be configured for Cisco/HDLC and traffic (non-PPP) may still flow.

pppUp 17 The fully operational state when PPP is enabled. PPP link negotiation has successfully completed and the link is available for normal data traffic.

pppDown 18 The non-operational state when PPP is enabled. PPP link negotiation has failed or the link has been administratively disabled.

pppWaitForOpen 20 PPP link negotiation state: Waiting for indication from PPP controller that auto-negotiation and related PPP control packet transfers can proceed. This is an inter-mediate state and should be used for informational purposes only.

pppAutoNegotiate 21 PPP link negotiation state: In process of exchanging PPP control packets (e.g., LCP and IPCP) to negoti-ate link parameters. This is an intermediate state and should be used for informational purposes only.

pppClose 22 PPP link negotiation state: The PPP session has been terminated. All data traffic will stop.

pppConnect 23 PPP link negotiation state: Negotiation has success-fully completed; the peers are logically connected. Normal data traffic may flow once the pppUp state is reached. This is an intermediate state and should be used for informational purposes only.

pppRestartNegotiation 28 PPP link negotiation state, following explicit request to restart negotiation process: this state indicates response to request.This is an intermediate state and should be used for informational purposes only.

pppRestartInit 29 PPP link negotiation state, following explicit request to restart negotiation process: the link has or will be brought down in order to begin a new negotiation cycle. This is an intermediate state and should be used for informational purposes only.


30 PPP link negotiation state, following explicit request to restart negotiation process: Waiting for indication from PPP controller that current connection is already down or is in process of being shut down. This is an intermediate state and should be used for informational purposes only.

Option Value Usage


statA

ospfFullNeighbors Read-only. 64-bit value. For OSPF - the number of OSPF neighbors that are fully up.

ospfTotalSessions Read-only. 64-bit value. For OSPF - the number of OSPF sessions that were config-ured.

overlayTemperature Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the Overlay chip.

oversize Read-only. 64-bit value. Number of oversized frames received (greater than 1518 bytes).

oversizeAndCrcErrors Read-only. 64-bit value. Only available for Gigabit modules. Number of frames received with oversize and CRC errors.

pathAis Read-only. A flag indicating whether any Path Alarm Indication Signals have been received on an OC ports for Packet over Sonet interfaces. Contains a value after the class method stat get statAllStats is used:


pathAisErroredSecs Read-only. 64-bit value. A count of the seconds during which (at any point during the second) at least one Path AIS error was detected.


31 PPP link negotiation state, following explicit request to restart negotiation process: Waiting for indication from PPP controller that shut down of current con-nection has completed.This is an intermediate state and should be used for informational purposes only.

pppRestartFinish 32 PPP link negotiation state, following explicit request to restart negotiation process: Preparation for restart completed; ready to begin normal cycle again. This is an intermediate state and should be used for infor-mational purposes only.

localProcessorDown 33 local processor boot failure

lossOfSignal 25 Physical link is down. (e.g., loss of signal, loss of frame)

lossOfFramePppDisabled

26 PPP link negotiation state: Physical link has gone down and PPP negotiation has been stopped.

stateMachineFailure 27 Communication with the local processor has failed. Check Server display and log for possible failure.

pppRestartNegotiatin 28 The restart PPP state machine has been activated.

pppRestartInit 29 Initializing the PPP state machine and commanding a restart to the PPP engine.


30 Waiting for the PPP engine to begin renegotiation.


31 Waiting for the PPP engine to close the PPP link prior to renegotiating the link.

pppRestartFinish 32 Renegotiation has started (LCP is in process) and control is transferring to the main PPP state machine.

localProcessorDown 33 The CPU on the port is not operating.

Option Value Usage


stat

pathAisUnavailableSecs Read-only. 64-bit value. A count of the seconds during which the STS path was con-sidered unavailable.

pathBip Read-only. 64-bit value. Number of Path Bit Interleaved Parity errors received on OC ports for Packet over Sonet interfaces.

pathBipErroredSecs Read-only. 64-bit value. A count of the seconds during which (at any point during the second) at least one Path BIP error was detected.

pathLossOfPointer Read-only. A flag indicating whether any Path LOP indications have been received on an OC ports for Packet over Sonet interfaces. Contains a value after the class method stat get statAllStats is used:


pathPlm Read-only. A flag indicating whether any Path Label Mismatch indications have been received on an OC ports for Packet over Sonet interfaces. Contains a value after the class method stat get statAllStats is used:


pathRdi Read-only. A flag indicating whether any Path Remote Defect Indicators (former FERF – Far End Receive Failure) have been received on an OC ports for Packet over Sonet interfaces. Contains a value after the class method stat get statAllStats is used:


pathRdiUnavailableSecs

Read-only. 64-bit value. A count of the seconds during which the STS path was consid-ered unavailable at the far end.

pathRei Read-only. 64-bit value. Number of Path Remote Error Indications (former FEBE – Far End Block Error) received on OC ports for Packet over Sonet interfaces.

pathReiErroredSecs Read-only. 64-bit value. A count of the seconds during which (at any point during the second) at least one STS Path error was reported by the far end.

pauseAcknowledge Read-only. 64-bit value. For 10Gbe – the number of received pause acknowledge messages.

pauseEndFrames Read-only. 64-bit value. For 10Gbe – the number of received pause end frame messages.

pauseOverwrite Read-only. 64-bit value. For 10Gbe – the temperature observed at the transmit FPGA.


statA

pauseState Read-only. Reflects whether the port is in pause transmit mode. The following states can be read:

plmDevice1InternalTemperature

Read-only. 64-bit value. Part of the OC-192 - Temperature Sensors Statistics. Temper-ature of the PLM measuring device #1 chip.





posK1Byte Read-only. 64-bit value. The current K1 byte code value being received in the Sonet frame.

posK2Byte Read-only. 64-bit value. The current K2 byte code value being received in the Sonet frame.

protocolServerRx Read-only. 64-bit value. Number of frames received by the protocol server when it is enabled using the protocolServer command.

protocolServerTx Read-only. 64-bit value. Number of frames transmitted by the protocol server when it is enabled using the protocolServer command.

qualityOfService0-7 Read-only. 64-bit value. Number of frames counted by Quality of Service Counter 0 through 7 that meet the criteria set up using the qos command. This counter is available when stat mode is set to statQos.

rsvpEgressLSPsUp Read-only. 64-bit value. The number of egress LSPs configured and running.

rsvpIngressLSPsConfigured

Read-only. 64-bit value. The number of ingress LSPs configured.

rsvpIngressLSPsUp Read-only. 64-bit value. The number of ingress LSPs configured and running.

rxArpReply Read-only. 64-bit value. Number of ARP reply frames received by the protocol server when it is enabled for ARP using the protocolServer command.

rxArpRequest Read-only. 64-bit value. Number of ARP request frames received from a DUT by the protocol server when it is enabled for ARP using the protocolServer command.

rxPingReply Read-only. 64-bit value. Number of PING reply frames received by the protocol server when it is enabled for PING using the protocolServer command.

rxPingRequest Read-only. 64-bit value. Number of PING request frames received from a DUT by the protocol server when it is enabled for PING using the protocolServer command. .

schedulerTemperature Read-only. 64-bit value. The temperature at the scheduler chip.

Option Value Usage

statIdle 0 transmit pause not enabled

statActive 1 transmit pause enabled


stat

sectionBip Read-only. 64-bit value. Number of section BIP errors received on OC ports for Packet over Sonet interfaces.

sectionBipErroredSecs Read-only. 64-bit value. A count of the number of seconds during which (at any point during the second) at least one section layer BIP was detected.

sectionLossOfFrame Read-only. 64-bit value. Number of section LOF indications received on OC ports for Packet over Sonet interfaces.

sectionLossOfSignal Read-only. 64-bit value. Number of section LOS indications received on OC ports for Packet over Sonet interfaces.

sectionLossOfSignalSecs

Read-only. 64-bit value. A count of the number of seconds during which (at any point during the second) at least one section layer LOS defect was present.

sequenceErrors Read-only. 64-bit value. Number of sequence errored frames.

sequenceFrames Read-only. 64-bit value. Number of signiture matched frames.

streamTrigger1 Read-only. 64-bit value. User-Defined Statistic counter 5 indicating number of frames received that meet the filtering criteria set up using the filter command. To use this counter the stat mode has to be set to statStreamTrigger.

streamTrigger2 Read-only. 64-bit value. User-Defined Statistic counter 6 indicating number of frames received that meet the filtering criteria set up using the filter command. To use this counter the stat mode has to be set to statStreamTrigger.

symbolErrorFrames Read-only. 64-bit value. Number of frames received with symbol errors (gigabit only).

symbolErrors Read-only. 64-bit value. Number of symbol errors.

synchErrorFrames Read-only. 64-bit value. Number of frames with synchronized errors (gigabit only).

tcpChecksumErrors Read-only. 64-bit value.

tcpPackets Read-only. 64-bit value.

tenGigLanRxFpgaTemperature

Read-only. 64-bit value. For 10Gbe – the temperature at the LAN receive FPGA.

tenGigLanTxFpgaTemperature

Read-only. 64-bit value. For 10Gbe – the temperature at the LAN transmit FPGA.

transmitDuration Read-only. 64-bit value. Transmit duration.

transmitState Read-only. Reflects the current state of transmit. The following states can be read:

Option Value Usage

statIdle 0 transmit stopped

statActive 1 port currently transmitting


statA

txArpReply Read-only. 64-bit value. Number of ARP reply frames transmitted for ARP requests received by the protocol server when it is enabled for ARP using the protocolServer command.

txArpRequest Read-only. 64-bit value. Number of ARP reply frames transmitted by the protocol server when it is enabled for ARP using the protocolServer command.

txPingReply Read-only. 64-bit value. Number of PING reply frames transmitted for PING requests received by the protocol server when it is enabled for PING using protocolServer command.

txPingRequest Read-only. 64-bit value. Number of PING request frames transmitted by the protocol server when it is enabled for PING using the protocolServer command.

udpChecksumErrors Read-only. 64-bit value.

udpPackets Read-only. 64-bit value.

undersize Read-only. 64-bit value. Number of undersized frames (less than 64 bytes) received.

usbRxBitStuffing Read-only. 64-bit value. Part of the USB Extended Statistics The last data packet received contained a bit stuffing violation.

usbRxBufferOverrun Read-only. 64-bit value. Part of the USB Extended Statistics. Receiving port receives data faster than it can be written to system memory.

usbRxCRCError Read-only. 64-bit value. Part of the USB Extended Statistics. Receiving port receives data faster than it can be written to system memory.

usbRxDataOverrun Read-only. 64-bit value. Part of the USB Extended Statistics. The amount of data returned exceeded the size of: the maximum data packet allowed, or the remaining amount of memory in the buffer.

usbRxdataUnderrun Read-only. 64-bit value. Part of the USB Extended Statistics. The endpoint sent less than maximum packet size, so the specified buffer is not filled.

usbRxDeviceNotResponding

Read-only. 64-bit value. Part of the USB Extended Statistics. The receive device did not respond to a token sent by the transmit device.

usbRxNoError Read-only. 64-bit value. Part of the USB Extended Statistics. Data packets received with no errors.

usbRxNotAccessed Read-only. 64-bit value. Part of the USB Extended Statistics. This code is set by the software before the DUT is placed in a queue for processing.

usbRxPIDCheckFail Read-only. 64-bit value. Part of the USB Extended Statistics. Check bits in the PID from the endpoint failed on data PID.

usbRxStall Read-only. 64-bit value. Part of the USB Extended Statistics. Received a Stall PID.

usbRxToggleMismatch Read-only. 64-bit value. Part of the USB Extended Statistics. The data toggle PID for the last data packet received did not match the expected value.


stat

usbRxUnexpectedPID Read-only. 64-bit value. Part of the USB Extended Statistics. Received an invalid PID or undefined PID value.

usbTxBufferUnderrun Read-only. 64-bit value. Part of the USB Extended Statistics. During transmission, can-not retrieve data from system memory and send out fast enough to keep up with the USB data rate.

usbTxDeviceNotResponding

Read-only. 64-bit value. Part of the USB Extended Statistics. The transmit device did not provide a handshake to the receive device.

usbTxNoError Read-only. 64-bit value. Part of the USB Extended Statistics. Data packets sent with no errors.

usbTxNotAccessed Read-only. 64-bit value. Part of the USB Extended Statistics. This code is set by soft-ware before the DUT is placed in a queue for processing.

usbTxPIDCheckFail Read-only. 64-bit value. Part of the USB Extended Statistics. Check bits in the PID from the endpoint failed on handshake

usbTxStall Read-only. 64-bit value. Part of the USB Extended Statistics. Transmitted a Stall PID.

usbTxUnexpectedPID Read-only. 64-bit value. Part of the USB Extended Statistics. Transmitted an invalid PID or undefined PID value.

userDefinedStat1 Read-only. 64-bit value. Number of frames counted by User Defined Statistics Counter 1 that meet the criteria set up using the filter command. This counter is available when stat mode is set to statNormal.

userDefinedStat2 Read-only. 64-bit value. Number of frames counted by User Defined Statistics Counter 2 that meet the criteria set up using the filter command. This counter is available when stat mode is set to statNormal.

vlanTaggedFramesRx Read-only. 64-bit value. Number of VLAN Tagged frames received.

COMMANDS The stat command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

stat cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the stat command. Specific errors include:

• Invalid statistic for port.

stat config option valueModify the configuration options of the statistics. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for capture.

stat get counterType chasID cardID portIDGets the statistics counter of type counterType. Note that the counterType is formed from the standard option name by prepending stat to the name and capi-talizing the first letter of the option. (E.g. for the option framesSent, the stat-


statA

Name is statFramesSent.) The special counterType allStats will make all of the statistics available through the options. A value of counterType other than all-Stats will make just that counter available through the counterVal option and the corresponding rate will be available through the counterRate option as well as the appropriately named option. Refer to Available Statistics for a list of the sta-tistics names and the cases under which they are available. (Actually, the counterType value is irrelevant in the operation of this command; any value, legal or not, will cause all statistics to be fetched as in allStats).

stat getCaptureState chasID cardID portIDReturns the capture state of the port. See the values associated with the captureState standard option.

stat getLineSpeed chasID cardID portIDReturns the line speed of the port. See the values associated with the lineSpeed standard option.

stat getLinkState chasID cardID portIDReturns the link state of the port. See the values associated with the link standard option.

stat getRate counterType chasID cardID portIDGets the frame rate for all stats. Note that the counterType is formed from the standard option name by prepending stat to the name and capitalizing the first letter of the option. (E.g. for the option framesSent, the statName is statFramesSent.) The special counterType allStats will make all of the statistics available through the options. Refer to Available Statistics for a list of the statis-tics names and the cases under which they are available.

stat getTransmitState chasID cardID portIDReturns the transmit state of the port. See the values associated with the transmitState standard option.

stat set chasID cardID portIDSets the configuration of the statistics counters on port portID, card cardID, chas-sis chasID in IxHAL Note - if the mode is set to anything other than statNormal, then up to 8 of the hardware counters will be reused for an alternate statistic.

stat setDefault

Sets the stat mode to default and zeros all stat counters.

stat write chasID chardID portIDWrites or commits the changes in IxHAL to hardware for port portID, card car-dID, chassis chasID. Before using this command, use the stat set command to configure the stream related options in IxHAL.


stat



# Assume that there’s a four port 10/100 TX card in this slot# with port 1 looped to port 2 and 3 to 4set card 1

# Procedure to set up a port group with ports 1 and 2proc setup {} \{ global group card chas set group 12

portGroup create $group portGroup add $group $chas $card 1 portGroup add $group $chas $card 2 port setFactoryDefaults $chas $card 1 port setFactoryDefaults $chas $card 2 portGroup write $group after 2000}

# Procedure to cleanup the port groupproc cleanup {} \{ global group portGroup destroy $group}

# Procedure to reset statistics and start transmission on the groupproc myStartTest {} \{ global group

if {[portGroup setCommand $group resetStatistics] != 0} \ { ixPuts “resetStatistics failed” } if {[portGroup setCommand $group startTransmit] != 0} \ { ixPuts “startTransmit failed” }}

# Procedure to stop transmission on the groupproc myStopTest {} \{ global group

if {[portGroup setCommand $group stopTransmit] != 0} \ { ixPuts “stopTransmit failed” }}

ixPuts “\tPort 1\t\t\t\tPort 2”ixPuts “\tSent\tRate\tRecv\tRate\tSent\tRate\tRecv\tRate”


statA

# Setup the port group and start the testsetupmyStartTest

# Once per second, get some statisticsfor {set i 1} {$i <= 5} {incr i} \{ after 1000

# Method #1 - do a get allStats and # then multiple cgets for individual stats if {[stat get allStats $chas $card 1] != 0} \ { ixPuts “error getting allStats for $chas $card 1” }

set framesSent1 [stat cget -framesSent] set framesRecv1 [stat cget -framesReceived] # then a getRate allStats for individual rate stats stat getRate allStats $chas $card 1 set framesSentRate1 [stat cget -framesSent] set framesRecvRate1 [stat cget -framesReceived]

# Method #2 - do a get for an individual stat # and then get the value and rate from counterVal/counterRate stat get statFramesSent $chas $card 2 set framesSent2 [stat cget -counterVal] set framesSentRate2 [stat cget -counterRate] stat get statFramesReceived $chas $card 2 set framesRecv2 [stat cget -counterVal] set framesRecvRate2 [stat cget -counterRate]

ixPuts -nonewline “$i\t$framesSent1\t$framesSentRate1” ixPuts -nonewline “$i\t$framesRecv1\t$framesRecvRate1” ixPuts -nonewline “$i\t$framesSent2\t$framesSentRate2” ixPuts “$i\t$framesRecv2\t$framesRecvRate2”}

myStopTestcleanup

SEE ALSO statGroup, statList


statGroup

NAME - statGroupstatGroup - gets the statistics on a set of ports.

SYNOPSIS statGroup sub-command options

DESCRIPTION The statGroup command is used to create a group of ports for the purpose of retrieving all of the statistics from the group or ports at the same time. Statistics retrieved through the use of the statGroup get sub-command are accessed through the use of the statList command.

STANDARD OPTIONS

numPorts Read-only. Indicates the number of ports currently in the list.

COMMANDS The statGroup command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

statGroup add chassisID cardID portIDAdds the indicated port to the list of ports in the group.

statGroup del chassisID cardID portIDDeletes the indicated port from the list of ports in the group.

statGroup cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the statGroup command.

statGroup get

Gets all of the valid statistics associated with each of the ports in the group. The group is formed by successive calls to statGroup add. The values of the statistics are available through the use of the statList command.

statGroup setDefault

Resets the list to empty.

EXAMPLES # add ports to get stats onstatGroup setDefaultforeach port $portList { scan $port “%d %d %d” c l p statGroup add $c $l $p}

# get the statsif {[statGroup get]} { ixPuts “Error getting stats for this group” set retCode 1}


statGroupA

# read statsstatList setDefaultforeach port $portList { scan $port “%d %d %d” c l p if {[statList get $c $l $p]} { continue } ixPuts “Frames transmitted: \ [statList cget -framesTransmitted]”

if {[statList getRate $c $l $p]} { continue } ixPuts “Transmit rate: [statList cget -framesTransmitted]”}

SEE ALSO statList, stat


statList

NAME - statListstatList - gets the statistics from ports previously collected with statGroup.

SYNOPSIS statList sub-command options

DESCRIPTION The statList command is used to get statistics previously read from the ports using the statGroup command. A single call to statList get is used to make all of the valid statistics for a port available through subsequent calls to statList cget. Similarly, rate statistics are made available through the use of statList getRate, followed by calls to statList cget.Note that the statName used in cgets is formed from the standard option name by prepending stat to the name and capitalizing the first letter of the option. (E.g. for the option framesSent, the statName is statFramesSent.) Refer to Available Statistics for a list of which statistics are available for particu-lar card modules and under particular circumstances.

STANDARD OPTIONS

See stat The STANDARD OPTIONS associated with statList are the same as those asso-ciated with stat, with the exception of the enable* and mode options.

COMMANDS The statList command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

statList cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the statList command.

statList get chasID cardID portIDMakes the statistics associated with a particular port accessible through the use of statList cget -option. Refer to Available Statistics for a list of the statistics names and the cases under which they are available.

statList getRate chasID cardID portIDMakes the rate statistics associated with a particular port accessible through the use of statList cget -option. Refer to Available Statistics for a list of the statistics names and the cases under which they are available.

statList setDefault

Clears all of the statistics previously collected with statGroup.

EXAMPLES See examples under statGroup.

SEE ALSO stat, statGroup


streamA

NAME - streamstream - configure the streams on a port of a card on a chassis.

SYNOPSIS stream sub-command options

DESCRIPTION The stream command is used to set up frames and bursts to be transmitted on a port of a card on a chassis. A maximum of 255 streams can be transmitted on each port. Some ports support fewer streams; consult the Ixia Hardware Guide for the exact numbers. A stream consists of bursts of frames separated by inter-frame gap and inter-burst gap (in nanoseconds). The source and destination MAC addresses, number of frames in a stream, pattern type, frame size, and inter-stream gap are some of the parameters that can be specified to shape the desired transmit traffic.

STANDARD OPTIONS

asyncIntEnable true/false

When this option is set to false, asynchronous transmit events cannot interrupt the stream. The asynchronous event is logged and will be invoked as soon as a synchronous stream will permit it. Note that only one asynchronous event of a type is logged, that is, if the same timer expired twice, only one asynchronous event is logged due to that counter. (default = false)

da Initial destination MAC address assigned to this stream. Specify this address as six hexadecimal numbers delimited by spaces or colons. For example, the following are valid address formats: {00 01 02 03 04 05} and {00:01:02:03:04:05}. (default = 00 00 00 00 00 00)

daMaskSelect Selects the bits in the 48-bit destination MAC address that are to be masked by the value set by daMaskValue. (default = 00 00 00 00 00 00)

daMaskValue Value of the masked bits selected by daMaskSelect in the destination MAC address. (default = 00 00 00 00 00 00)

daRepeatCounter Specifies how the destination MAC address will be incremented or decremented. Possible values include:

Option Value Usage

increment 0 increment the MAC address for as many numDA specified

contIncrement 1 Continuously increment the MAC address for each frame

decrement 2 decrement the MAC address for as many numDA specified

contDecrement 3 Continuously decrement the MAC address for each frame

idle 4 (default) no change to MAC address regardless of numDA

ctrRandom 5 Generate random destination MAC address for each frame


stream

dataPattern type Sets up the default data pattern to be inserted into the frames of this stream. type may be one of the following values:

dma mode This determines the behaviour of the stream flow. The mode may be one of the following:

daArp 6 the first frame in this stream is sent out as an ARP Request. The DUT MAC address is extracted out of the ARP Response received from the DUT and stored as the new DA for the rest of the frames in the stream.

Option Value Usage

Option Value Usage

allOnes 0 the frame contains all 1's

allZeroes 1 the frame contains all 0's

xAAAA 2 the frame contains all A's

x5555 3 the frame contains all 5's


xDDDD 5 the frame contains all D's

xF0F0 6 the frame contains repeating pattern of F0F0's

x0F0F 7 the frame contains repeating pattern of 0F0F's

xFF00FF00 8 the frame contains repeating pattern of FF00FF00's

x00FF00FF 9 the frame contains repeating pattern of 00FF00FF's

xFFFF0000 10 the frame contains repeating pattern of FFFF0000's

x0000FFFF 11 the frame contains repeating pattern of 00000FFFF's

x00010203 12 (default) the frame contains repeating pattern of 00010203's

x00010002 13 the frame contains repeating pattern of 00010002's

xFFFEFDFC 14 the frame contains repeating pattern of FFFEFDFC's

xFFFFFFFE 15 the frame contains repeating pattern of FFFFFFFE's

userpattern 16 select this type to insert user-defined data pattern in the frame

Option Value Usage

contPacket 0 (default) continuously transmit the frames on this stream

contBurst 1 continuously transmit bursts of frames on this stream

stopStream 2 stop all transmission from the port where this stream resides regardless of existence of other streams on this port

advance 3 after all the frames are sent from the current stream, the frames from the next stream on the port are transmitted.

gotoFirst 4 the last stream on the port is set to this mode to begin transmission of frames of the first stream in the list

firstLoopCount 5 the last stream on the port is set to this mode to begin transmission of the first stream in the list for loopCount intervals


streamA

enable true/false Enable or disable the stream. If disabled, the frames in this stream will not be transmitted along with the other streams on this port. (default = true)

enableIbg true/false Enable the inter-burst gap. (default = true)

enableIsg true/false Enable the inter-stream gap. (default = true)

enforceMinGap When a port which supports this feature is in Advanced Scheduler Mode, then this is the minimum gap that will ever be inserted between packets. The smallest value supported is 3. (default = 12)

fcs type The FCS error to be inserted in the frame. type can be one of the following:

fir true/false If Frame Identity Record (FIR) is set to true, 6 bytes of timestamp will be inserted before the CRC of the frame. (default = false)

framerate Read-only. It reflects the actual rate in frames per second that this configured stream will transmit at.

framesize Number of bytes in each frame in the stream. All frames in the stream have the same size. The minimum framesize so as to enable capture on OC12 ports is 48 bytes. (default = 64)

frameSizeMAX The maximum frame size to be used when frame size of type sizeRandom is selected. (default = 1518)

frameSizeMIN The minimum frame size to be used when frame size of type sizeRandom is selected. (default = 64)

frameSizeType May assume one of the following values:

frameType The type field in the Ethernet frame, which does not apply to the MAC layer frames. (default = { })

Option Value Usage

good 0 (default) a good FCS to be inserted in the frame

alignErr 1 an alignment error to be inserted in the frame (only valid for 10/100)

dribbleErr 2 dribble error to be inserted in the frame

bad 3 a bad FCS error to be inserted in the frame

none 4 no FCS error to be inserted in the frame

Option Value Usage

sizeFixed 0 (default) all frames in the stream where this packet has been defined have a fixed size specified by framesize option

sizeRandom 1 frames with random sizes are generated on the stream on which the frames are defined

sizeIncr 2 every frame generated on the stream will have incre-menting size

sizeAuto 3 frame size is automatically calculated. Used for pro-tocols that have variable frame lengths such as DHCP.


stream

gapUnit Gap may be one of the following unit values:

ibg Inter-Burst Gap is the delay between bursts of frames in clock ticks (see ifg option for definition of clock ticks). If the IBG is set to 0 then the IBG is equal to the ISG and the IBG becomes disabled. (default = 24.000000)

ifg The inter-frame gap specified in clock ticks (default = 24.000000). The following is the conversion method from clock ticks to nanoseconds for 10, 100 and 1000 speeds and the minimum IFGs that can be specified:

10 Mbps: 1 clock tick = 400 nanoseconds. Minimum IFG is 24 clock ticks = 9600 nanoseconds.



ifgMAX The maximum inter-frame gap in clock ticks to be used when IFG of type gapRandom is selected. (default = 24.000000)

ifgMIN The minimum inter-frame gap in clock ticks to be used when IFG of type gapRandom is selected. (default = 24.000000)

ifgType type type may be one of the following values:

isg The inter-stream gap is the delay in clock ticks at the start of each stream. This delay comes after the receive trigger is enabled. Setting this option to 0 means no delay. (default = 24.000000)

loopCount Number of times to begin transmission of the first stream in the list when stream config –dma firstLoopCount is set. (default = 1)

name User specified name of the stream. (default =””)

numBursts Number of bursts in the stream. If the option dma is set to contBurst or contPacket this option will be ignored. (default = 1)

Option Value Usage

gapNanoSeconds 0 Sets units of time for gap to nanoseconds

gapMicroSeconds 1 Sets units of time for gap to microseconds

gapMilliSeconds 2 Sets units of time for gap to milliseconds

gapSeconds 3 Sets units of time for gap to seconds

gapClockTicks 4 (default) Sets units of time for gap to clock ticks of load module card. The number of clock ticks varies between load modules. Ixia recommends that you do not use this option. This option is planned for depre-cation in the next release.

Option Value Usage

gapFixed 0 (default) the gap between all frames is fixed

gapRandom 1 random size of gap is generated between every frame transmitted (not supported yet)


streamA

numDA Number of destination MAC addresses the stream is going to be transmitted to. numDA must be > 1 in order to set the daRepeatCounter to anything other than idle. (default = 1)

numFrames Number of maximum frames in the stream. If the option dma is set to contPacket this option will be ignored. (default = 100)

numSA Number of source MAC addresses on the stream which is going to transmit frames from. numSA must be > 1 in order to set the saRepeatCounter to anything other than idle. (default = 1)

packetView Read-only. Displays the frames as they are going to be transmited. NOTE: Shows the first frame when the transmitMode is set to portTxPacketStreams and shows all the frames when transmitMode is set to portTxPacketFlows.

pattern Specify a user-defined pattern of data to be transmitted on this stream. The dataPattern option must be set to type userPattern or this pattern will be ignored. (default = “00 01 02 03”)

patternType type Type of given patterns that will be inserted in all the frames transmitted on this stream. type can be one of the following:

percentPacketRate If stream config –rateMode is set to usePercentRate, then use this value as a percent of maximum transmit rate for this stream. This command sets all three gaps: IFG, IBG and ISG.. (default = 100.0)

preambleSize Number of bytes in the preamble field of the frame. Range is between 2 and 255. (default = 8)

rateMode Specifies whether to use the ifg or percentPacketRate to calculate stream gap. Possible values include:

NOTE: if usePercentRate is used, then the stream config -rateMode usePercentRate command should be the first command after stream setDefault.

Option Value Usage

incrByte 0 (default) increment each byte of the frame during transmission

incrWord 1 increment each word of the frame during transmis-sion

decrByte 2 decrement each byte of the frame during transmis-sion

decrWord 3 decrement each word of the frame during

patternTypeRandom 4 generate random pattern of data during transmission

repeat 5 transmit the same pattern of data in the frame

nonRepeat 6 transmit a fixed pattern of data. NOTE: Fixed type in IxExplorer.

Option Value Usage

useGap 0 (default) use the stream ifg

usePercentRate 1 use percentPacketRate


stream

region Reserved for future use and should always be left at its default value of 1. (default = 1)

returnToId streamID Configures the stream number (streamID) that control will loop to. (default = 1)

rxTriggerEnable true/false

When set to true, the transmit engine waits for a pulse from the receiver to start the stream. (default = false)

sa Initial source MAC address assigned to this stream. Specify this address as six hexadecimal numbers delimited by spaces or colons. For example, the following are valid address formats: {00 01 02 03 04 05} and {00:01:02:03:04:05}. (default = 00 00 00 00 00 00)

saMaskSelect Selects the bits in the 48-bit source MAC address that are to be masked by the value set by saMaskValue. (default = 00 00 00 00 00 00)

saMaskValue Value of the masked bits selected by saMaskSelect in the source MAC address. (default = 00 00 00 00 00 00)

saRepeatCounter Specifies how the source MAC address will be incremented or decremented. Possible values include:

INTERNAL OPTIONS

floatRate Read-only. The framerate option expressed as a floating point number.

COMMANDS The stream command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

stream cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the stream command.

Option Value Usage

increment 0 increment the MAC address for as many numSA specified

contIncrement 1 continuously increment the MAC address for each frame

decrement 2 decrement the MAC address for as many numSA specified

contDecrement 3 continuously decrement the MAC address for each frame

idle 4 (default) no change to MAC address regardless of numSA

ctrRandom 5 generate random source MAC address for each frame

cpeMacAddress 7 for ports operating in USB mode, use the source MAC address provided by the DUT (customer premise equipment).


streamA

stream config option valueModify the configuration options of the stream. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for stream.

stream export fileName chasID cardID portID [fromStreamID toStreamID]Exports the current stream contents of the port at portID, cardID, chasID into the file named fileName. The range of streams is expressed by the range of fromStre-amID (default = 1) and toStreamID (default = 0). If fromStreamId is less than or equal to 0 the first stream is used and if toStreamID is 0, then all streams are exported. The file produced by this command may be used by the import sub-command. Specific errors are:

• No connection to a chassis• Stream IDs are not valid• Invalid port

stream get chasID cardID portID streamIDGets the current configuration of the stream with id streamID on port portID, card cardID, chassis chasID. from its hardware. Call this command before call-ing stream cget option value to get the value of the configuration option.

stream import fileName chasID cardID portIDImports saved stream contents found in the file fileName into the port at portID, cardID, chassis chasID. All of the streams found in the file are appended to the currently defined streams. The file used by this command must have been pro-duced by the export sub-command. Specific errors are:

• No connection to a chassis• Invalid port• The card is owned by another user• fileName does not exist• fileName does not contain valid data

stream send chasID cardID portID streamIDSend a start transmit on one individual stream: streamID to port portID, card car-dID, chassis chasID.

stream set chasID cardID portID streamIDSets the configuration of the stream with id streamID on port portID, card car-dID, chassis chasID in IxHAL by reading the configuration option values set by the stream config option value command.

stream setDefault

Sets default values for all configuration options.NOTE: The command stream setDefault also overwrites the udf set command.

stream setFactoryDefault

Sets factory default values for all configuration options.


stream

stream setGaps ifg chasID cardID portID streamIDA helper command that sets the inter-frame gap, inter-stream gap and inter-burst gap specified by ifg for the frames in the stream with id streamID on port portID, card cardID, chassis chasID in IxHAL and then commits to hardware.

stream setIFG ifg chasID cardID portID streamIDA helper command that sets the inter-frame gap specified by ifg for the frames in the stream with id streamID on port portID, card cardID, chassis chasID in IxHAL and then commits to hardware.

stream setLoopCount loopcount chasID cardID portID streamIDA helper command that sets the loopcount in the stream with id streamID on port portID, card cardID, chassis chasID in IxHAL and then commits to hardware.

stream setNumFrames numFrames chasID cardID portID streamIDA helper or convenience command that sets the number of frames specified by numFrames in the stream with id streamID on port portID, card cardID, chassis chasID in IxHAL and then commits to hardware.

stream write chasID cardID portID streamIDWrites or commits the changes in IxHAL to hardware for stream with id strea-mID on port portID, card cardID, chassis chasID. Before using this command, use the stream set command to configure the stream related options in IxHAL.

DEPRECATED COMMANDS

stream getPacketView


# Connect to chassis and get chassis IDset host galaxyixInitialize $hostset chas [ixGetChassisID $host]set card 1set port 1set portList [list [list $chas $card $port]]


# In this example, we’ll set up two streams on the port:# Any parameters not mentioned are factory defaults## 1) Name = First# Advance to next stream# 1000 packets per burst# 10 bursts# IPG = 1000ns# IBG = 2000ns# ISG = 3000ns# Data = repeating 55 55


streamA

# Random frame sizes from 100 - 1000 bytes# DA = Arp table# SA = 04 05 06 07 08 09# 2) Name = Last# Return to ID # 1 for a count of 10# 5000 packets per burst# 1 burst# IPG = 10000ns# Random frame sizes from 100 - 1000 bytes# DA = Arp table# SA = 04 05 06 07 08 09

# Make sure the port is at factory defaultport setFactoryDefaults $chas $card $port

# Setup stream 1stream setDefaultstream config -name “First”stream config -dma advancestream config -numFrames 1000stream config -numBursts 10stream config -gapUnit gapNanoSecondsstream config -rateMode useGapstream config -ifg 1000stream config -ifgType gapFixedstream config -enableIbg truestream config -ibg 2000stream config -enableIsg truestream config -isg 3000stream config -patternType repeatstream config -dataPattern x5555stream config -frameSizeType sizeRandomstream config -frameSizeMIN 100stream config -frameSizeMAX 1000stream config -daRepeatCounter daArpstream config -saRepeatCounter idlestream config -sa {04 05 06 07 08 09}stream set $chas $card $port 1

# Setup stream 2stream setDefaultstream config -name “Last”stream config -dma firstLoopCountstream config -returnToId 1stream config -loopCount 10stream config -numFrames 5000stream config -numBursts 1stream config -gapUnit gapNanoSecondsstream config -rateMode useGapstream config -ifg 10000stream config -ifgType gapFixedstream config -enableIbg falsestream config -enableIsg falsestream config -daRepeatCounter daArpstream config -saRepeatCounter idlestream config -sa {04 05 06 07 08 09}stream set $chas $card $port 2


SEE ALSO port


tcp

NAME - tcptcp - configure the TCP parameters for a port on a card on a chassis

SYNOPSIS tcp sub-command options

DESCRIPTION The tcp command is used to configure the TCP-specific information used when building TCP type packets if ip config –ipProtocol has been set to Tcp. See RFC 793 for a complete definition of TCP header fields.

STANDARD OPTIONS

acknowledgementNumber

Next byte that the receiver expects from the sending host. (default = 0)

acknowledgeValid true/false

Indicates whether the acknowledgement number field is valid. (default = false)

destPort Protocol source port number. (default = 0)

finished true/false The sender indicates that this is the last packet it will transmit for the connection. (default = false)

offset Offset from the beginning of the TCP header to the data. (default = 5)

options Variable length option field in the TCP header. Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. (default = { })

pushFunctionValid true/false

Request that receiver deliver the packet to the application without buffering. (default = false)

resetConnection true/false

Reset the connection signal. (default = false)

sequenceNumber Sequence number used to keep track of each byte of data. (default = false)

sourcePort Protocol destination port number. (default = 0)

synchronize true/false Indicates either a connection request (ACK=0) or a connection accepted (ACK=1) condition. (default = false)

urgentPointer Byte offset of the urgat data in the packet. (default = 0)

urgentPointerValid true/false

Indicates whether the urgent point field is valid. (default = false)

window The number of bytes that the recipient may send to the sender, starting at the acknowledge byte. (default = 0)


tcpA

COMMANDS

The tcp command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

tcp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the tcp command.

tcp config option valueModify the TCP configuration options of the port. If no option is specified, returns a list describing all of the available TCP options (see STANDARD OPTIONS) for port.

tcp decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. tcp cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used.

tcp get chasID cardID portIDGets the current TCP configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling tcp cget option to get the value of the configuration option.

tcp set chasID cardID portIDSets the TCP configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the tcp config option value command.

tcp setDefault







port setFactoryDefaults $chas $card $txPortport setDefault


tcp


# Set up IP: lowcost packets# Source address varies by incrementing the network part# Destination address varies by incrementing the host partip setDefaultip config -cost lowCostip config -sourceIpAddr $portIPip config -sourceIpMask $portMaskip config -sourceClass classCip config -destIpAddr $destIPip config -destIpMask $destMaskip config -destClass classCip set $chas $card $port


tcp setDefaulttcp config -sourcePort 32768tcp config -destPort 21tcp set $chas $card $port


SEE ALSO stream, protocol, ip


tcpRoundTripFlowA

NAME - tcpRoundTripFlowtcpRoundTripFlow - configure the tcp round trip flow parameters for a port on a card on a chassis

SYNOPSIS tcpRoundTripFlow sub-command options

DESCRIPTION The tcpRoundTripFlow command is used to configure the tcp round trip flow specific information used when setting the tcp round trip flow on a port.

STANDARD OPTIONS

dataPattern type Sets up the default data pattern to be inserted into the streams on the port. type may be one of the following values:

forceIpSA true/false Forces the IP source address in reflected packets, as defined in the ipSA option. (default = false)

framesize Number of bytes in each frame in the tcp round trip flow. (default = 64)

gatewayIpAddr Gateway IP address. (default = 0.0.0.0)

ipSA IP source address. (default = 0.0.0.0)

macDA Mac destination address. (default={00 00 00 00 00 00})

macSA Mac source address. (default={00 00 00 00 00 00})

Option Value Usage

allOnes 0 the frame contains all 1's

allZeroes 1 the frame contains all 0's

xAAAA 2 the frame contains all A's



xDDDD 5 the frame contains all D's

xF0F0 6 the frame contains repeating pattern of F0F0's

x0F0F 7 the frame contains repeating pattern of 0F0F's

xFF00FF00 8 the frame contains repeating pattern of FF00FF00's

x00FF00FF 9 the frame contains repeating pattern of 00FF00FF's

xFFFF0000 10 the frame contains repeating pattern of FFFF0000's

x0000FFFF 11 the frame contains repeating pattern of 00000FFFF's

x00010203 12 (default) the frame contains repeating pattern of 00010203's

x00010002 13 the frame contains repeating pattern of 00010002's

xFFFEFDFC 14 the frame contains repeating pattern of FFFEFDFC's

xFFFFFFFE 15 the frame contains repeating pattern of FFFFFFFE's

userpattern 16 select this type to insert user-defined data pattern in the frame, as defined in pattern


tcpRoundTripFlow

pattern Specify a user-defined pattern of data to be transmitted on this stream. The dataPattern option must be set to type userPattern or this pattern will be ignored (default= {00 01 02 03})

patternType type Type of given patterns that will be inserted in all the frames transmitted on the tcp round trip flow stream. type can be one of the following:

useArpTable true/false Enable ARP Mac destination address option. (default = false)

COMMANDS The tcpRoundTripFlow command is invoked with the following sub-com-mands. If no sub-command is specified, returns a list of all sub-commands avail-able.

tcpRoundTripFlow cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the tcpRoundTripFlow command.

tcpRoundTripFlow config option valueModify the tcp round trip flow configuration options of the port. If no option is specified, returns a list describing all of the available the tcpRoundTripFlow options (see STANDARD OPTIONS) for port.

tcpRoundTripFlow get chasID cardID portIDGets the current tcp round trip flow configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling tcpRoundTrip-Flow cget option to get the value of the configuration option.

tcpRoundTripFlow set chasID cardID portIDSets the tcp round trip flow configuration of the port with id portID on card car-dID, chassis chasID by reading the configuration option values set by the tcpRoundTripFlow config option value command.

tcpRoundTripFlow setDefault


Option Value Usage

incrByte 0 increment each byte of the frame during transmission (default)

incrWord 1 increment each word of the frame during transmis-sion

decrByte 2 decrement each byte of the frame during transmis-sion

decrWord 3 decrement each word of the frame during

patternTypeRandom 4 generate random pattern of data during transmission

repeat 5 transmit the same pattern of data in the frame trans-mission

nonRepeat 6 transmit a fixed pattern of data. NOTE: Fixed type in IxExplorer.


tcpRoundTripFlowA

tcpRoundTripFlow setFactoryDefaults chasID cardID portIDSets the factory defaults to the tcpRoundTripFlow.


# In this example, two ports on a 10/100 card are connected through a # simple switch. The first port transmits at 100Mb/s and the second# port transmits at 10Mb/s. ## The second port uses TCP Round Trip Flows to reflect the received# packets back to port 1, where they are captured and analyzed for# latency using captureBuffer.


# Assumes that card 1 is a 10/100 card with both ports connected to # a simple L2 switchset card 1set txPort 1set rxPort 2

# Useful port listsset portList [list [list $chas $card $txPort] \ [list $chas $card $rxPort]]set txPortList [list [list $chas $card $txPort]]set rxPortList [list [list $chas $card $rxPort]]

# Test parameters# Port 1’s MAC addressset p1MAC [list 00 00 00 01 01 01]# Port 2’s MAC addressset p2MAC [list 00 00 00 01 01 02]# Port 1’s IP addressset p1IP “192.168.18.1” # Port 2’s IP addressset p2IP “192.168.18.2”# Number of frames to transmitset numFrames 10


# Port 1: 100Mb/sport setFactoryDefaults $chas $card $txPortport config -speed 100port config -advertise100FullDuplex trueport config -advertise100HalfDuplex falseport config -advertise10FullDuplex falseport config -advertise10HalfDuplex false

# Stream: 1 stream @ 100%, frame size 100, specific number of frames# Make sure to insert time stamps (fir)


tcpRoundTripFlow

stream setDefaultstream config -enable truestream config -dma stopStreamstream config -numBursts 1stream config -numFrames $numFramesstream config -rateMode usePercentRatestream config -percentPacketRate 100stream config -sa $p1MACstream config -da $p2MACstream config -framesize 100stream config -fir true

# IP: ethernetII tcp packets from port to portip setDefaultip config -ipProtocol tcpip config -sourceIpAddr $p1IPip config -sourceIpAddrRepeatCount 1ip config -sourceIpAddrMode fixedip config -destIpAddr $p2IPip config -destIpAddrRepeatCount 1ip config -destIpAddrMode fixedip set $chas $card $txPort

tcp setDefaulttcp set $chas $card $txPort


# Set the stream and portsstream set $chas $card $txPort 1port set $chas $card $txPort

# Set up Receive Port

# Port 2: 10Mb/s, TCP round trip mode reflects 64 byte packetsport setFactoryDefaults $chas $card $rxPortport setDefaultport config -speed 10port config -advertise100FullDuplex falseport config -advertise100HalfDuplex falseport config -advertise10FullDuplex trueport config -advertise10HalfDuplex falseport config -transmitMode portTxPacketFlowsport config -receiveMode portRxTcpRoundTrip

# Set up TCP RT for Mac addressestcpRoundTripFlow setDefaulttcpRoundTripFlow config -macSA $p2MACtcpRoundTripFlow config -macDA $p1MACtcpRoundTripFlow set $chas $card $rxPort

# Set the portport set $chas $card $rxPortixWritePortsToHardware portList

# Wait for changes to take affectafter 1000ixCheckLinkState portList

# Send the packets and wait for things to be doneixClearStats txPortList


tcpRoundTripFlowA

ixStartCapture txPortListixStartTransmit txPortList

after 1000ixCheckTransmitDone txPortList

# Fill the capture buffer with all of the packetscapture get $chas $card $txPortset numRxFrames [capture cget -nPackets]if {$numRxFrames != $numFrames} \{ ixPuts “$numFrames transmitted, but $numRxFrames received”}

captureBuffer get $chas $card $txPort 1 [expr $numRxFrames - 1]

# Figure out the latency and print it outcaptureBuffer getStatisticscaptureBuffer getConstraint 1ixPuts -nonewline “Avg Latency is “ixPuts -nonewline [captureBuffer cget -averageLatency]ixPuts -nonewline “ns, min = “ixPuts -nonewline [captureBuffer cget -minLatency]ixPuts -nonewline “ns, max = “ixPuts -nonewline [captureBuffer cget -maxLatency]ixPuts “ns”

SEE ALSO stream, ip, tcp


timeServer

NAME - timeServertimeServer - configure the timing parameters for a chassis.

SYNOPSIS timeServer sub-command options

DESCRIPTION The timeServer command is used to manage the timing of the chassis chain. It includes controls and read-only values for all timing options available on IXIA 100 and IxClock chassis.

STANDARD OPTIONS

antennaStatus Read-only. Possible values include:

cdmaFrameErrorRate Read-only. The CDMA frame error rate, expressed in errored frames per second.

cdmaSNR Read-only. The CDMA signal to noise ratio.

cdmaState Read-only. The current state of the CDMA unit. Possible values include:

cdmaTime Read-only. CDMA generated time in seconds.

e1T1Status Read-only for IxClock only. The status of the E1 or T1 signal. Possible values include:

Option Value Usage

gpsStateAntennaUnknown 0 antenna status is unknown until status is received from the GPS unit

gpsStateAntennaOK 1 antenna is connected and working

gpsStateAntennaOpen 2 antenna is not detected

gpsStateAntennaShort 3 antenna is not working

Option Value Usage

cdmaStateAntennaUnknown

0 CDMA status is unknown until status is received.

cdmaStateAcquiring 1 acquiring a signal

cmdaStateSignalDetected 2 a CDMA signal has been detected

cdmaStateCodeLocking 3 CDMA code locking in progresss

cdmaStateCarrierLocking 4 CDMA carrier locking in progress

cdmaStateLocked 5 CDMA code and carrier are locked; valid times are available

Option Value Usage

ixClockE1T1None 0 no signal is detected

ixClockE1T1Error 1 an error has been detected

ixClockE1T1OK 2 signal is OK


timeServerA

enableValidStatstrue / false

If set, then timeServer cget -statName calls for statistics invalid for the time source will return an error. If unset, then all timeServer cget -statName will return without error, but the invalid statistics will have default values. (default = true)

gpsStatus Read-only. Possible values include:

gpsTime Read-only. GPS generated time in seconds.

pllStatus Read-only. Possible values include:

qualityStatus Read-only. Possible values include:

sntpClient The name or IP address of the SNTP server used to obtain time information from. Used when timeSource is set to sntpClient. (default = ““)

state Read-only. The current state of the GPS unit expressed as a string.

timeOfDay Read-only for IxClock only. The current time of day, expressed as a string.

timeSource Indicates the source for the time server:

Option Value Usage

gpsStateGpsUnknown 0 GPS status is unknown until status is received

gpsStateGpsLocked 1 connection to the GPS is established

gpsStateGpsUnlocked 2 connection to the GPS is not established

Option Value Usage

gpsStatePLLUnknown 0 PLL status is unknown until status is received

gpsStatePLLOK 1 PLL is locked

gpsStatePLLUnlocked 2 PLL is not synchronized to the satellite

Option Value Usage

tsTimeQualityInvalid 0 quality invalid until status is received

tsTimeQuality0 1 perfect timing

tsTimeQuality1 2 acceptable timing

tsTimeQuality2 3 not acceptable timing



Option Value Usage

tsInternal 0 use internal timing for chassis.

tsGpsServer 1 use the GPS unit.

tsSntpServer 2 use an external SNTP server in sntpClient.

tsPcClock 3 use the clock from the PC associated with the chassis.

tsE1 4 (IxClock only) use the E1 clock input

tsT1 5 (IxClock only) use the E1 clock input

ts1PPS 6 (IxClock only) use the 1PPS clock input

tsStandAlone 7 use stand-along timing for the chassis

tsCdma 8 use the CDMA unit


timeServer

COMMANDS The timeServer command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

timeServer cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the timeServer command, subject to the setting of the enableValidStats option.

timeServer config option valueModify the configuration options of the time server. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for timeServer.

timeServer get chasIDGets the current configuration of the TimeServer for chassis with chassis ID chasID from its hardware. Call this command before calling timeServer cget option value to get the value of the configuration option.

timeServer resetGps chasID Resets the GPS unit in chassis ID chasID.

timeServer set chasID Sets the time server configuration of the chassis with chassis ID chasID by read-ing the configuration option values set by the timeServer config option value command.

timeServer setDefault



set host localhostixInitialize $hostset chas [ixGetChassisID $host]# Get the type of chassis so that we use GPS correctlychassis get $hostset type [chassis cget -type]# Set the time server selection to the defaulttimeServer setDefaulttimeServer set $chaschassis writeAll $chas

# And check the current settingstimeServer get $chasset ts [timeServer cget -timeSource]ixPuts -nonewline “Default time source is: “switch $ts \ $::tsInternal{ixPuts “internal”} \ $::tsGpsServer{ixPuts “GPS”} \ $::tsSntpServer{ixPuts “SNTP”} \ $::tsPcClock{ixPuts “PC Clock”} \ $::tsE1 {ixPuts “E1”} \ $::tsT1 {ixPuts “T1”} \ $::tsStandAlone{ixPuts “stand alone”} \ $::tsCdma{ixPuts “CDMA”}


timeServerA

# If the chassis is of a type that has GPSif {$type == $::ixia100} \{ # Set it to GPS mode timeServer config -timeSource tsGpsServer timeServer set $chas chassis writeAll $chas

# Wait for a minute to see if we can achieve good quality for {set i 0} {$i < 60} {incr i} \ { after 1000

# Get the settingstimeServer get $chas# Get the GPS time qualityset quality [timeServer cget -qualityStatus]# If it’s good enoughif {$quality <= $::tsTimeQuality1} \{ ixPuts “Good GPS quality achieved” break}# Otherwise report on all settingsixPuts “Quality is $quality”

set quality [timeServer cget -antennaStatus]ixPuts “Antenna Status is $quality”

set quality [timeServer cget -gpsStatus]ixPuts “GPS Status is $quality”

set quality [timeServer cget -pllStatus]ixPuts “PLL Status is $quality”

set quality [timeServer cget -state]ixPuts “State is $quality”

}

# If we achieved lock if {$i < 60} \ {

# Pick up the time setting set time [timeServer cget -gpsTime]

ixPuts “Current time from GPS is $time” } else \ { ixPuts “Can’t achieve GPS lock”

break }}

# Now try to set the system to use CDMAtimeServer config -timeSource tsCdmatimeServer set $chaschassis writeAll $chas

SEE ALSO chassisChain


udf

NAME - udfudf - configure the User-Definable Fields in the frames of a stream.

SYNOPSIS udf sub-command options

DESCRIPTION User-Definable Fields (UDFs) are counters that can be inserted anywhere in the frame whose data can be used to represent special purpose patterns. Up to four UDFs can be specified. Each of them can be enabled or disabled and contain 8, 16, 24, or 32 bit counters.

STANDARD OPTIONS

continuousCount true/false

When set to true, the counter will increment or decrement the bytes depending on the updown option. (default = false)

countertype type Describes the size and shape of this UDF field. Each field consists of 4 8-bit counters; these counters may be configured as individual counters or in any combination, such as 2 8-bit counters & one 16 bit counter, 2 16-bit counters, or 1 32 bit counter. Note that every 8-bit counter within this field does not have to be used. The options available for this variable select the size (8, 16, 24 or 32 bits) and configuration; for example - if the option c8x8x8x8 is selected the counters will be configured as 4 independent 8-bit counters. If the option config8x16 is selected, the counters will be configured as one 8-bit counter, one 16-bit counter and the remaining 8-bits will be unused. The following values can be specified for this option:

enable true/false If this option is set to true, then this UDF counter will be inserted into the frame. (default = false)

Option Value Usage

c8 0 one 8-bit counter

c16 1 one 16 bit counter

c8x8 2 (default) two 8-bit counters


c16x8 4 one 16-bit counter followed by a 8-bit counter


c8x8x8 6 three 8-bit counters



c16x16 9 two 16-bit counters

c16x8x8 10 one 16-bit counter followed by two 8-bit counters


c8x16x8 12 one 8-bit counter followed by a 16-bit counter fol-lowed by another 8-bit counter

c8x8x16 13 two 8-bit counters followed by a 16-bit counter

c8x8x8x8 14 four 8-bit counters


udfA

enableCascade true/false

If this option is set to true, then the UDF counter will not be reset with the start of each stream, but will rather continue counting from the ending value of the previous stream. This is only available for OC48 modules. (default = false)

initval The initial value of the counter. (default = 08 00)

maskselect This is a 32-bit mask that enables, on a bit-by-bit basis, use of the absolute counter value bits as defined by maskval option. (default = 00 00)

maskval A 2-bit mask of absolute values for this UDF counter. It is used in association with the maskselect; bits must be set 'on' or the bits in maskselect will be ignored. (default = 00 00)

offset The absolute offset to insert this udf into the frame. Note that DA and SA use the fixed offsets at 0 and 6, respectively. (default = 52)

random true/false If this object is set to true, then this counter will contain random data. The UDFs may not have part counter and part random data. (default = false)

repeat The counter is incremented or decremented the number of times based on this option. If continuousCount option is set then this value is ignored. (default = 1)

updown This option describes whether each of the 8-bit counters are to be incremented or decremented. If two or more counters are cascaded together as a larger counter (ie, 16,24 or 32-bit counter), that group of counters must all be incremented or decremented. Note that the most-significant byte selection will take precedence if there is a discrepancy. The possible values of this options are:

Option Value Usage

uuuu 15 (default) all bytes are incrementing

uuud 14 bytes 1,2 and 3 are incrementing and byte 4 is decrementing

uudu 13 bytes 1,2 and 4 are incrementing and byte 3 is decrementing

uudd 12 bytes 1 and 2 are incrementing and bytes 3 and 4 are decre-menting

uduu 11 bytes 1,3 and 4 are incrementing and byte 2 is decrementing

udud 10 bytes 1 and 3 are incrementing and bytes 2 and 4 are decre-menting

uddu 9 bytes 1 and 4 are incrementing and bytes 2 and 3 are decre-menting

uddd 8 byte 1 is incrementing and bytes 2,3 and 4 are decrementing

duuu 7 byte 1 is decrementing and bytes 2,3 and 4 are incrementing

duud 6 bytes 1 and 4 are decrementing and bytes 2 and 3 are incre-menting

dudu 5 bytes 1 and 3 are decrementing and bytes 2 and 4 are incre-menting

dudd 4 bytes 1,3 and 4 are decrementing and byte 2 is incrementing

dduu 3 bytes 1 and 2 are decrementing and bytes 3 and 4 are incre-menting

ddud 2 bytes 1,2 and 4 are decrementing and byte 3 is incrementing

dddu 1 bytes 1,2 and 3 are decrementing and byte 4 is incrementing

dddd 0 all bytes are decrementing


udf

COMMANDS The udf command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

udf cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the udf command.

udf config option valueModify the configuration options of the port. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for port.

udf get udfIDAfter using stream get command, this command will get the UDF with id udfID.

udf set udfIDSets the configuration of the UDF with ID udfID by reading the configuration option values set by the udf config option value command. stream set must be called after setting this UDF.NOTE: The command stream setDefault also overwrites the udf set command.

udf setDefault



# Connect to chassis and get chassis IDset host galaxyixInitialize $hostset chas [ixGetChassisID $host]set card 1set port 1set portList [list [list $chas $card $port]]

# In this example, we’ll set up three of the udfs for stream 1:# Any parameters not mentioned are factory defaults## 1) UDF 1# Offset 12# Single 8 bit counter# Continuously counting up# Initial value 0# 2) UDF 2# Offset 24# Counter type 16x8# Repeat Count = 1000# 16 bit counter counts up# 8 bit counter downs down from 0xFF with a mask of XXXXXXX0# 3) UDF 3# Offset 36# Single 8 bit counter# Random values

# Make sure the port is at factory defaultport setFactoryDefaults $chas $card $port


udfA

stream setDefault

# Setup UDF 1udf setDefault udf config -enable trueudf config -offset 12udf config -countertype c8udf config -continuousCount trueudf config -updown uuuuudf config -initval 00udf set 1

# Setup UDF 2udf setDefault udf config -enable trueudf config -offset 24udf config -countertype c16x8udf config -continuousCount falseudf config -updown uuduudf config -initval {00 00 FF}udf config -repeat 1000udf config -maskselect {00 00 01 00}udf config -maskval {00 00 00 00}udf set 2

# Setup UDF 3udf setDefault udf config -enable trueudf config -random trueudf config -offset 36udf config -countertype c8udf set 3

# Make sure to use stream set to set the UDFsstream set $chas $card $port 1ixWritePortsToHardware portList

SEE ALSO stream


udp

NAME - udpudp - configure the UDP parameters for a port on a card on a chassis

SYNOPSIS udp sub-command options

DESCRIPTION The udp command is used to configure the UDP-specific information used when building UDP type packets if ip config –ipProtocol has been set to Udp. See RFC 768 for a complete definition of UDP header fields.

STANDARD OPTIONS

checksum Value of the checksum in the valid udp stream. Valid only if the stream set is performed and enableChecksumOverride is true. (default = 00 00)

destPort The port of the destination process. Well-known port values include:

enableChecksum true/false

If set to true, a valid UDP checksum will be calculated for each frame. If set to false, the UDP checksum will be invalid. (default = false)

enableChecksumOverride true/false

If set to true, the calculated checksum will be replaced with the value in checksum. (default = false)

length Length of the datagram including header and the data. (default = 0)

lengthOverride true/false

Allows to change the length in udp header. (default = false)

Option Value Usage

echoServerPort 7 (default)

discardPacketPort 9

usersServerPort 11

dayAndTimeServerPort 13

quoteOfTheDayServerPort 17

characterGeneratorPort 19

timeServerPort 37

whoIsServerPort 43

domainNameServerPort 53

unassignedPort 63

bootpServerPort 67

bootpClientPort 68

tftpProtocolPort 69

remoteWhoServerPort 513

ripPort 520


udpA

sourcePort The port of the sending process. Well-known port values include:

COMMANDS The udp command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

udp cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the udp command.

udp config option valueModify the UDP configuration options of the port. If no option is specified, returns a list describing all of the available UDP options (see STANDARD OPTIONS) for port.

udp decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. udp cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used.

udp get chasID cardID portIDGets the current UDP configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling udp cget option to get the value of the configuration option.

udp set chasID cardID portIDSets the UDP configuration of the indicated port by reading the configuration option values set by the udp config option value command.

udp setDefault


Option Value Usage

echoServerPort 7 (default)

discardPacketPort 9

usersServerPort 11

dayAndTimeServerPort 13

quoteOfTheDayServerPort 17

characterGeneratorPort 19

timeServerPort 37

whoIsServerPort 43

domainNameServerPort 53

unassignedPort 63

bootpServerPort 67

bootpClientPort 68

tftpProtocolPort 69

remoteWhoServerPort 513

ripPort 520


udp






port setFactoryDefaults $chas $card $portport setDefault


# Set up IPip setDefaultip config -ipProtocol udpip config -sourceIpAddr $portIPip config -sourceIpMask $portMaskip config -sourceClass classCip config -destIpAddr $destIPip config -destIpMask $destMaskip config -destClass classCip set $chas $card $port


udp setDefaultudp config -sourcePort 53udp config -destPort 53udp set $chas $card $port


SEE ALSO stream, protocol, ip


usbA

NAME - usbusb - view the properties of a USB port of a card on a chassis.

SYNOPSIS usb sub-command options

DESCRIPTION The usb command is used to view the properties of a USB port of a card on a chassis.

STANDARD OPTIONS

cpeMacAddress Read-only. The MAC address of the CPE (Customer Premise Equipment).

deviceClass Read-only. Class of the attached device, according to the document: Universal Serial Bus Class Definitions for Communication Devices Version 1.1 January 19, 1999.

ethernetMaxSegmentSize

Read-only. The maximum Ethernet segment size.

manufacturer Read-only. Manufacturer of the attached device.

maxUSBPacketSize Read-only. The maximum size of the USB packets. Either:

In 64 bytes, out 64 bytes (0)In 32 bytes, out 32 bytes (1)

product Read-only. The product name of the device which is attached.

productID Read-only. The product identification number of the attached device.

releaseNumber Read-only. Release level of USB supported by the attached device.

serialNumber Read-only. Serial number of the attached device.

vendorID Read-only. Select this radio button to put this module into USB mode.

COMMANDS The usb command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

usb get chasID cardID portIDGets the current configuration of the port with id portID on card cardID, chassis chasID. from its hardware. Call this command before calling usb cget option value to get the value of the configuration option. Specific errors are:

• No connection to a chassis• Invalid port number• The port is not a Usb port.


usb

usb reset chasID cardID portIDSends a reset signal to the device on the port with id portID on card cardID, chas-sis chasID.

usb setDefault



# Connect to chassis and get chassis IDset host localhostixInitialize $hostset chas [ixGetChassisID $host]# Assuming that Ethernet/USB or USB card is in slot 16set card 16set portList [list [list $chas $card 1]]


# Get the type of card and check if it’s the correct typeset cardType [card cget -type]if {$cardType == $::cardUsb} \{ port config -portMode portUsbUsb port set $chas $card 1 ixWriteConfigToHardware portList} \else{ ixPuts “Card $card is not a Ethernet/USB card” exit}

# Reset the usb cardusb setDefaultusb reset $chas $card 1

# Get the current usb state from the cardusb get $chas $card 1

# Read back one of the current valuesset cpeMac [usb cget -cpeMacAddress]ixPuts “Device serial number is $cpeMac”

SEE ALSO card, port


versionA

NAME - versionversion - get version information for IxTclHal.

SYNOPSIS version sub-command options

DESCRIPTION This command allows the user to view the version information for IxTclHal. Note that when using Tcl from a Unix system, the version may not be obtained until a connection to the chassis is made, for example through the use of ixInitial-ize.

STANDARD OPTIONS

companyName Read-only. The name of company: Ixia Communications

copyright Read-only. Copyright banner for IxTclHal

installVersion Read-only. Installed version of the software.

ixTclHALVersion Read-only. The version number of ixTclHal.dll file

productVersion Read-only. The software version along with build number

COMMANDS The version command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

version cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the version command.

version config

Modify the version configuration options of the IxTclHal. If no option is speci-fied, returns a list describing all of the available version options (see STAN-DARD OPTIONS).

version get

Gets the current version information from HAL. Call this command before call-ing version cget option to get the value of the configuration option.


version get

ixPuts -nonewline “Company name is “ixPuts [version cget -companyName]ixPuts -nonewline “Copyright is “ixPuts [version cget -copyright]ixPuts -nonewline “Install Version is “ixPuts [version cget -installVersion]


version

ixPuts -nonewline “ixTclHAL Version is “ixPuts [version cget -ixTclHALVersion]ixPuts -nonewline “Product Version is “ixPuts [version cget -productVersion]

SEE ALSO


vlanA

NAME - vlanvlan - configure the VLAN parameters for a port on a card on a chassis

SYNOPSIS vlan sub-command options

DESCRIPTION The vlan command is used to configure the VLAN-specific information used when building 802.1q-type packets. See IEEE 802.1p/q for a complete definition of VLAN tag fields. It is enabled using protocol config -enable802dot1qTag true

STANDARD OPTIONS

cfi Canonical Format Indicator is a single bit flag value. Options include:

maskval For all but the Idle VLAN ID mode, theis option indicates which bits of the VID counter may vary and which must remain constant. (default = 0000XXXXXXXXXXXX)

mode Specifies how the vlanID tag will be incremented or decremented. Possible values include:

repeat The number of times the counter is to be repeated with the same value. If mode option is set to idle then this value is ignored. (default = 10)

userPriority The user priority field is three bits in length, representing eight priority levels, 0 though 7. The use and interpretation of this field is defined in ISO/IEC 15802-3. (default = 0)

vlanID The 12-bit VLAN Identifier (VID). (default = 0)

Option Value Usage

resetCFI 0 (default) sets the CFI bit to low

setCFI 1 sets the CFI bit to high

Option Value Usage

vIdle 0 (default) no change to VlanID tag regardless of repeat vIncrement 1 increment the VlanID tag for as many repeat specified

vDecrement 2 decrement the VlanID tag for as many repeat specified

vContIncrement 3 Continuously increment the VlanID tag for each frame

vContDecrement 4 Continuously decrement the VlanID tag for each frame

vCtrRandom 5 Generate random VlanID tag for each frame


vlan

COMMANDS The vlan command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

vlan cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the vlan command.

vlan config option valueModify the vlan configuration options of the port. If no option is specified, returns a list describing all of the available vlan options (see STANDARD OPTIONS) for port.

vlan decode capFrame [chasID cardID portID]Decodes a captured frame in the capture buffer and updates TclHal. vlan cget option command can be used after decoding to get the option data. If chasID, cardID and portID are omitted, then packet offsets for Ethernet packets are used.

vlan get chasID cardID portIDGets the current UDP configuration of the port with id portID on card cardID, chassis chasID. Call this command before calling vlan cget option to get the value of the configuration option.

vlan set chasID cardID portIDSets the vlan configuration of the port with id portID on card cardID, chassis chasID by reading the configuration option values set by the vlan config option value command.

vlan setDefault





stream setDefault

protocol setDefaultprotocol config -name ipV4protocol config -ethernetType ethernetIIprotocol config -enable802dot1qTag true

vlan setDefaultvlan config -vlanID 42vlan config -mode vIncrementvlan config -repeat 10vlan set $chas $card $port


vlanA



SEE ALSO stream, protocol


vlan


vlanA


BAppendix B: Utility Commands

Ixia Tcl Development Guide B-1

byte2IpAddrB

NAME - byte2IpAddrbyte2IpAddr - convert 4 hex bytes into an IP address in dotted notation

SYNOPSIS byte2IpAddr <hexVal>

DESCRIPTION The byte2IpAddr command converts 4 hex bytes into an IP address in dotted notation. It can be used in scripts where IP addresses are read from the capture buffer in hexadecimal format, for example.

EXAMPLE byte2IpAddr “C0 02 0A 0C”

Returns 192.2.10.12

SEE ALSO dectohex, hextodec, host2addr

B-2 Ixia Tcl Development Guide

calculateFrameRate

NAME - calculateFrameRatecalculateFrameRate - calculates the frame rate, in frames/second

SYNOPSIS calculateFrameRate ifgap frame_size frame_preambleSize speed

DESCRIPTION The calculateFrameRate command calculates the frame rate based on the IFG, frame size, preamble size and interface speed.

COMMAND The calculateFrameRate command is invoked with the following arguments.calculateFrameRate ifgap frame_size frame_preambleSize speed

where:ifgap – inter-frame gap, in clock ticks

frame_size – frame size, in bytes

frame_preambleSize – preamble size, in bytes

speed – interface speed, i.e. 10/100/1000 Mbps, in Mbps

SEE ALSO calculateGap


calculateGapB

NAME - calculateGapcalculateGap - calculates the inter-frame gap, in clock ticks

SYNOPSIS calculateGap frame_rate frame_size frame_preambleSize speed

DESCRIPTION The calculateGap command calculates the IFG in clock ticks, based on the frame rate, frame size, preamble size and interface speed. See command stream config –ifg for definition of clock ticks.

COMMAND The calculateGap command is invoked with the following arguments.calculateGap frame_rate frame_size frame_preambleSize speed

where:frame_rate – frame rate, in frames per second

frame_size – frame size, in bytes

frame_preambleSize – preamble size, in bytes

speed – interface speed, i.e. 10/100/1000 Mbps, in Mbps

SEE ALSO calculateFrameRate


dectohex

NAME - dectohexdectohex - convert a decimal number to a hexadecimal number

SYNOPSIS dectohex <decimal number>

DESCRIPTION The dectohex command converts a decimal number to a hexidecimal number.

EXAMPLE dectohex 10

Returns A

SEE ALSO hextodec, host2addr, byte2IpAddr


disableUdfsB

NAME - disableUdfsdisableUdfs - disables all UDFs in the argument list

SYNOPSIS disableUdfs udfIDlist

DESCRIPTION The disableUdfs command cycles through all the udf numbers in the list argu-ment list and disables them.

COMMAND The disableUdfs command is invoked with the following arguments.disableUdfs udfList

where udfList is a list of UDF numbers 1 to 4.

SEE ALSO udf, stream


fastpath

NAME - fastpathfastpath - sends some packets to set up the fastpath/shortcut in the DUTNOTE: This command replaces the ipfastpath command.

SYNOPSIS fastpath sub-command options

DESCRIPTION The fastpath command sends some packets to set up the fastpath/shortcut in the DUT.

STANDARD OPTIONS

calculateLatency Capture fastpath frames and calculate the fastpath latency (default=no).

enable Enable/disable transmitting fastpath frames (default=false).

framesize Size of fastpath frame, does not have to be the same framesize as the test frame (default=64).

numframes Number of fastpath frames to transmit (default=10).

rate Frame rate to transmit fastpath frames, in fps (default=100).

waitTime Time to allow the transmit engine to complete transmission and update stats, in ms (default=2000).

COMMAND The fastpath command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

fastpath cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the fastpath command.

fastpath config option valueModify the configuration options of the fastpath. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for fastpath.

fastpath setDefault


fastpath show

Displays the current settings of the fastpath.

INTERNALCOMMANDS

The following commands are internal interfaces, for use only by Ixia. Use of these commands may produced undesirable results and are not guaranteed to be backward compatible in future releases:exists, getHelp, getType, getValidRange, getValidValues, getValidateProc


hextodecB

NAME - hextodechextodec - convert a hexidecimal number to a decimal number

SYNOPSIS hextodec <hex number>

DESCRIPTION The hextodec command converts a hexadecimal number to a decimal number.

EXAMPLE hextodec 7a

Returns 122

SEE ALSO dectohex, host2addr, byte2IpAddr


host2addr

NAME - host2addrhost2addr - convert an IP address in dotted notation to a list of hex bytes

SYNOPSIS host2addr <IP address>

DESCRIPTION The host2addr command converts an IP address in dotted notation to a list of hex bytes. This command is useful in scripts where the user specifies an IP address in dotted notation and it needs to be converted into 4 hexadecimal byte format to store as a list.

EXAMPLE host2addr 192.1.10.12

Returns C0 01 0A 0C

SEE ALSO dectohex, host2addr, byte2IpAddr


learnB

NAME - learnlearn - configure learn frames

SYNOPSIS learn sub-command options

DESCRIPTIONThe learn command is used to configure the parameters of learn frames. Layer 2, or MAC learn frames, are sent by the receive ports before the traffic is transmit-ted in order to allow the DUT to ‘learn’ or setup its address table. If the selected protocol is IP, ARP frames are sent from both the transmit and receive ports in order to learn the MAC address of the DUT port and to allow the DUT to learn the IP addresses. If the selected protocol is IPX, RIPx frames are sent to allow the DUT to learn the socket addresses of the connected ports.

STANDARD OPTIONS

framesize Size, in bytes, of the frames to transmit. Specified framesize must be a valid framesize, i.e., greater than/equal to 64, less than/equal to 1518 (default = 64)

numDHCPframes Number of DHCP frames to transmit. (default = 1)

numframes Total number of learn frames per address to be sent. (default = 10)

rate Transmit rate (in fps) at which the learning frames will be transmitted. (default = 100)

retries Number of retries to check for arp response. (default = 10)

waitTime Delay time after all learning frames are sent to allow the DUT to settle down after its learning process. (default = 1000)

when Learn frames can be sent at the following times during the execution of the test:

once - learning frames are sent before the trials of the testonTrial - learning frames are sent at the beginning of each trial of the testonIteration - for tests that have several iteration within each trial, learning

frames will be sent at the beginning of each iterationnever - learning frames are not sent at all

DEPRICATED STANDARD OPTIONS

errorAction If set to “remove”, any ports that misbehaved during the arp process will be removed from the map. (default =continue)

COMMAND The learn command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.


learn

learn cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the learn command.

learn config option value

Modify the configuration options of the learn. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for learn.

learn config option valueModify the configuration options of learn. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for fastpath.

learn setDefault


learn show

This command is used to show learn parameters.

INTERNALCOMMANDS



logMsgB

NAME - logMsglogMsg - logs text to the log file

SYNOPSIS logMsg [-nonewline] arg...

DESCRIPTION The logMsg command outputs its arguments to the log file with or without a newline.

ARGUMENTS

-nonewline If present, suppresses a newline at the end of the output

arg ... Arguments which are concatenated together and written to the log file.

RETURNS

0 No error; the command was successfully delivered to the IxServer

1 Error; the command was delivered to the IxServer but it could not process the message

EXAMPLE logMsg -nonewline “This will write to the logFile”

SEE ALSO logOn, logOff, logger, ixPuts


logOff

NAME - logOfflogOn - disables logging.

SYNOPSIS logOff

DESCRIPTION The logOff command is used to turn off logging.

STANDARD OPTIONS

None

SEE ALSO ixProxyConnect, logger, logOn


logOnB

NAME - logOnlogOn - enables logging.

SYNOPSIS logOn filename

DESCRIPTION The logOn command is used to turn on logging. The log file is configured with the command.

STANDARD OPTIONS

filename The filename to log output under.

SEE ALSO ixProxyConnect, logger, logOff


logger

NAME - loggerlogger - configure log parameters.

SYNOPSIS logger sub-command options

DESCRIPTION The logger command is used to configure log parameters.

STANDARD OPTIONS

fileBackup true/false If logging is on and fileBackup is set to true, it will rename the log file name and create a new log file, otherwise the log file gets overwritten. (default=false)

logFileName The name of the log file. (default=default.log)

directory Sets the log directory. (default=c:\ixia\TclTk\TclScripts\Logs)

COMMAND The logger command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

logger cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the logger command.

logger config option valueModify the configuration options of the log. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for log-ger.

logger message logStreamThis command is used to write messages to the log file.

logger off

This command is used to turn off logging to the log file.

logger on

This command is used to turn on logging to the log file. This command returns the time when logging started.

logger setDefault


logger show

This command is used to show log parameters.

INTERNALCOMMANDS

The following commands are internal interfaces, for use only by Ixia. Use of these commands may produced undesirable results and are not guaranteed to be backward compatible in future releases:exists, getHelp, getType, getValidRange, getValidValues, getValidateProcstartTime, endTime, fileID and ioHandle,


mapB

NAME - mapmap - configure traffic map.

SYNOPSIS map sub-command options

DESCRIPTION The map command is used to set the direction of traffic flow between ports on same or different cards on same or different chassis. There are four types of map-pings available - one2one, one2many, many2one and many2many.The one2one mapping sets up one transmit and one receive port for traffic flow. The transmit/receive port pair that has been configured once cannot be used in a different port pair. That is, each port pair is mutually exclusive. The one2many mapping sets up one transmit port and multiple receive ports. Each group of transmit and its multiple receive ports is mutually exclusive with other groups. The many2one mapping sets up multiple transmit ports and one receive port. Each group of multiple transmit ports and its receive port is mutually exclusive with other groups. The many2many mapping sets up multiple transmit ports and multiple receive ports. Any port may transmit and receive to any other port in any group of ports.

STANDARD OPTIONS

type maptype maptype may be one of:

one2one one2many many2onemany2many

COMMAND The map command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

map add txChassis txLm txPort rxChassis rxLm rxPortCreates a map from Tx ports txPort on card txLm, chassis txChassis to Rx port rxPort on card rxLm, chassis rxChassis.

map cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the map command.

map config option valueModify the configuration options of the map. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for map.

map del txChassis txLm txPort rxChassis rxLm rxPortDeletes a map from Tx ports txPort on card txLm, chassis txChassis to Rx port rxPort on card rxLm, chassis rxChassis.


map

map new typeClears the current map of type one2one, one2many, many2one, or many2many.

map setDefault


map show typeDisplays the current settings of the map of type one2one, one2many, many2one or many2many on stdout. If no type is specified, displays all map types.

INTERNALCOMMANDS



mpexprB

NAME - mpexprmpexpr - performs arbitrary precision arithmetic

SYNOPSIS mpexpr <expression>

DESCRIPTION mpexpr works much like Tcl’s native expr, but does all calculations using an arbitrary precision math package. mpexpr numbers can be any number of digits, with any decimal precision. Final precision is controlled by a Tcl variable mp_precision, which can be any reasonable integer, limiting only the number of digits to the right of the decimal point.

COMMAND The mexpr command should be used on all 64-bit values as marked in the cita-tions below.

SEE ALSO


user

NAME - useruser - configure the user related parameters

SYNOPSIS user sub-command options

DESCRIPTION The user command is used to configure user related information. This informa-tion is used when the RFC2544, RFC 2285 and non-RFC tests are executed and results are produced. It helps in the identification of the user and used for refer-ence.

STANDARD OPTIONS

comments A comment associated with the test.

productname Name of the DUT being tested.

version Version number of the product.

serial# Serial number of the product.

username The name of the user running the tests.

COMMAND The user command is invoked with the following sub-commands. If no sub-com-mand is specified, returns a list of all sub-commands available.

user cget optionReturns the current value of the configuration option given by option. Option may have any of the values accepted by the user command.

user config option valueModify the configuration options of the user. If no option is specified, returns a list describing all of the available options (see STANDARD OPTIONS) for user.

user setDefault


INTERNALCOMMANDS



validateFramesizeB

NAME - validateFramesizevalidateFramesize - validate the framesize to be a valid ethernet framesize

SYNOPSIS validateFramesize arg

DESCRIPTION The validateFramesize command checks the arg to see if it falls within the range of 64 to 1518 bytes.

COMMAND The validateFramesize command is invoked with the following arguments.

validateFramesize framesize

SEE ALSO validatePreamblesize


validatePreamblesize

NAME - validatePreamblesizevalidatePreamblesize - validate the preamble size

SYNOPSIS validatePreamblesize arg

DESCRIPTION The validatePreamblesize command checks the arg to see if it falls within the range of 2 to 255 bytes.

COMMAND The validatePreamblesize command is invoked with the following arguments.

validatePreamblesize preambleSize

SEE ALSO validateFramesize


validatePreamblesizeB


CArguments to the high-level APIs are passed in one of two ways:

• By value–denoted by (By value) in the description. By value argu-ments are either a constant or a $variable reference. For example:

{{1 1 1} {1 2 1}} -or- $portList• By reference–denoted by (By reference) in the description. By refer-

ence arguments must be references to variables, without the ‘$’. For example, pl after set pl {{1 1 1} [1 1 2}}.

Almost all commands return a value of 0 on successful operation. This can be symbolically referred to as $TCL_OK in a global context or $TCL_OK other-wise. In the examples in this section, a value of 0 will be used.

Similarly predefined quantities such as one2oneArray are defined in the global context. If your program is running in other than the global context then it is necessary to include a double colon () before the constant or variable name. For example, one2oneArray.

Appendix C: High-Level API

Ixia Tcl Development Guide C-1

ixCheckLinkStateC

NAME - ixCheckLinkStateixCheckLinkState - checks the link state on a group of ports

SYNOPSIS ixCheckLinkState portList

DESCRIPTION The ixCheckLinkState command checks the link state on a group of ports. This command must be called in the beginning of the script to ensure that all links are up before any traffic is transmitted to the DUT.

NOTE: It should be preceded by an after 1000 statement following the previous command, in order to allow the effects of the previous command to have an effect on the port hardware. The value of 1000 (one second) may need adjust-ment, based on the number of ports changed.

ARGUMENTS

portList (By reference) The list of ports in one of the following formats:

one2oneArray, one2manyArray, many2oneArray, many2manyArrayOr a reference to a list. E.g. pl after

set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS

0 Links on all ports are up.

1 Link on one or more ports is down.


set host galaxyixInitialize $host

set chassis 1set cardA 1set portA 1set cardB 1set portB 2

map new -type one2onemap config -type one2onemap add $chassis $cardA $portA $chassis $cardB $portBmap add $chassis $cardB $portB $chassis $cardA $portA

port setDefaultport set $chassis $cardA $portAport set $chassis $cardB $portB

stream setDefault stream config -dma stopStreamstream config -numFrames 100000

C-2 Ixia Tcl Development Guide

ixCheckLinkState

stream set $chassis $cardA $portA 1

stream config -numFrames 200000stream set $chassis $cardB $portB 1

ixWritePortsToHardware one2oneArray

# wait for write ports to have an effectafter 1000

if {[ixCheckLinkState one2oneArray] != 0} {ixPuts "One or more links are down"

}

SEE ALSO


ixCheckOwnershipC

NAME - ixCheckOwnershipixCheckOwnership - checks the ownership for a list of ports

SYNOPSIS ixCheckOwnership portList

DESCRIPTION The ixCheckOwnership command checks the ownership on a list of ports; the port list must be passed by value. It accepts * as a wild card to indicate all cards or all ports on a card. A wild card cannot be used for chassis ID. Also, if a com-bination of a list element containing wild cards and port numbers are passed, then the port list passed MUST be in a sorted order, otherwise the some of those ports might not make it in the list.

ARGUMENTS

portList (By value) The list of ports in one of the following formats:

One of the following literal strings, or a reference to a variable with the $ (e.g. $pl after set pl ...){{1 1 1}}{{1 1 1} {1 1 2} {1 1 3} {1 1 4}}{{1 1 *} {1 2 1} {1 2 2}}{1,1,* 1,2,1 1,2,2}

RETURNS

0 All of the ports are available for the ‘taking’.

100 One or more of the ports are owned by someone else.



# Login George and take ownership of 1, 2, 2ixLogin georgeset portListG [list [list 1 2 2]]ixTakeOwnership $portListG force

# Login Bill and make a port list for all ports on cards 1 and 2ixLogin billset portListB [list [list 1 1 *] [list 1 2 *]]

# This should fail because 1, 2, 2 is owned by Georgeif {[ixCheckOwnership $portListB] == 0} { ixPuts "Ports $portListB are available"} else { ixPuts "One or more of $portListB are unavailable"}

# Now we’ll avoid that port and express the list a different wayset portListB [list 1,1,* 1,2,1]


ixCheckOwnership

if {[ixCheckOwnership $portListB] == 0} { ixPuts "Ports $portListB are available"} else { ixPuts "One or more of $portListB are unavailable"}

SEE ALSO ixClearOwnership, ixLogin, ixLogout, ixPortClearOwnership, ixPortTakeOwn-ership, ixTakeOwnership


ixCheckPPPStateC

NAME - ixCheckPPPStateixCheckPPPState - checks the PPP state on a group of POS ports

SYNOPSIS ixCheckPPPState portList [mesage]

DESCRIPTION The ixCheckPPPState command checks the PPP state of all PoS ports in a group of ports in parallel and labels the ones that are down. Then it polls the links that are down for two seconds and returns 1 if any port is still down and a 0 if all ports are up.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

message (By value) (Optional, default = messageOn) Indicates that a message with the ports’ state is to be written to STDOUT or not.

RETURNS

0 Links on all ports are up.

1 Link on one or more ports is down.





if {[ixCheckPPPState one2oneArray] != 0} { ixPuts "PPP is down"}

SEE ALSO


ixCheckPortTransmitDone

NAME - ixCheckPortTransmitDoneixCheckPortTransmitDone - checks whether transmission is done on a port

SYNOPSIS ixCheckPortTransmitDone chassisID cardID portID

DESCRIPTION The ixCheckPortTransmitDone command polls the transmit rate statistic counter and returns when transmission has stopped. Note: this command should be called no earlier than one second after starting transmit with ixStartTransmit or ixStartPortTransmit.


ARGUMENTS

chassisID (By value) The ID number of the chassis.

cardID (By value) The ID number of the card.

portID (By value) The ID number of the port.

RETURNS

0 Error; either no frames were sent or the stat get framesSent command failed.

NumTxFrames No Error; number of frames transmitted since the last time statistics were cleared.

EXAMPLES package require IxTclHalset host galaxyixInitialize galaxy

set chas 1set cardA 1set portA 4set portList [list [list $chas $cardA $portA]]

port setDefaultport set $chas $cardA $portA

stream setDefault stream config -dma stopStreamstream config -numFrames 100000stream set $chas $cardA $portA 1

ixWritePortsToHardware portListafter 1000if {[ixCheckLinkState portList] != 0} { ixPuts "Link is not up"}


ixCheckPortTransmitDoneC

# Start transmit and wait a bitixStartPortTransmit $chas $cardA $portAafter 1000

# Check if the port has stoppedixCheckPortTransmitDone $chas $cardA $portAixPuts "PortA Stopped transmitting"

SEE ALSO ixCheckTransmitDone


ixCheckTransmitDone

NAME - ixCheckTransmitDoneixCheckTransmitDone - checks whether transmission is done on a group of ports

SYNOPSIS ixCheckTransmitDone portList

DESCRIPTION The ixCheckTransmitDone command polls the transmit rate statistic counter and returns when transmission is stopped. No value is returned. Note: this com-mand should be called no earlier than one second after starting transmit with ixStartTransmit or ixStartPortTransmit.


ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS

0 Success

1 Failure.

EXAMPLES package require IxTclHalset host galaxyixInitialize galaxy

set chas 1set cardA 1set portA 1set cardB 1set portB 2

# Examples of four ways to make a port listset portList1 [list $chas,$cardA,$cardA]set portList2 [list $chas,$cardA,$cardA $chas,$cardB,$portB]set portList3 [list [list $chas $cardA $cardA] [list $chas $cardB $portB]]set portList4 [list [list $chas,$cardA,$cardA] [list $chas,$cardB,$portB]]

map new -type one2onemap config -type one2onemap add $chas $cardA $portA $chas $cardB $portB


ixCheckTransmitDoneC

map add $chas $cardB $portB $chas $cardA $portA

port setDefaultport set $chas $cardA $portAport set $chas $cardB $portB


stream config -numFrames 200000stream set $chas $cardB $portB 1

ixWritePortsToHardware one2oneArrayafter 1000if {[ixCheckLinkState one2oneArray] != 0} { ixPuts "Link is not up"}

# Start transmit and wait a bitixStartTransmit one2oneArrayafter 1000

# Check if the first port has stoppedixCheckTransmitDone portList1ixPuts "PortA Stopped transmitting"

# Check if both ports have stoppedixCheckTransmitDone portList2ixPuts "PortA & PortB Stopped transmitting"

ixStartTransmit one2oneArrayafter 1000

# Check if both ports have stopped, a different wayixCheckTransmitDone portList3ixPuts "PortA & PortB Stopped transmitting"

ixStartTransmit one2oneArrayafter 1000

# Check if both ports have stopped, yet another wayixCheckTransmitDone portList4ixPuts "PortA & PortB Stopped transmitting"

ixStartTransmit one2oneArrayafter 1000ixCheckTransmitDone one2oneArrayixPuts "PortA & PortB Stopped transmitting"

SEE ALSO ixCheckPortTransmitDone


ixClearArpTable

NAME - ixClearArpTableixClearArpTable - clears the arp table on a group of ports simultaneously

SYNOPSIS ixClearArpTable portList

DESCRIPTION The ixClearArpTable command clears the arp table via the protocol server.

ARGUMENTS

ixClearArpTable (By reference) The list of ports in one of the following formats:


set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS

0 No error; the command was successfully delivered to the IxServer.

1 Error; the command was delivered to the IxServer but it could not process the message.





if {[ixClearArpTable one2oneArray] != 0} { ixPuts "ARP table could not be cleared"} else { ixPuts "ARP table cleared"}

SEE ALSO ixClearPortArpTable


ixClearOwnershipC

NAME - ixClearOwnershipixClearOwnership - clears ownership of all the ports in the list

SYNOPSIS ixClearOwnership [portList] [takeType]

DESCRIPTION The ixClearOwnership command clears ownership of all the ports in the list.

ARGUMENTS



A value of ““ (default) will clear ownership of all Tcl owned ports.

takeType (By value) (Optional) Valid values:

force – take regardless of whether the port is owned by someone elsenotForce – (default) do not force ownership

RETURNS





set portList1 {{1 1 1}}set portList2 {{1 1 1} {1 1 2} {1 1 3} {1 1 4}}set portList3 {{1 1 *} {1 2 1} {1 2 2}}

if {[ixClearOwnership $portList1] != 0} { ixPuts "Could not clear ownership for $portList1\n"}if {[ixClearOwnership $portList2] != 0} { ixPuts "Could not clear ownership for $portList2\n"}if {[ixClearOwnership $portList3 notForce] != 0} { ixPuts "Could not clear ownership for $portList3\n"}

SEE ALSO ixTakeOwnership, ixPortClearOwnership, ixPortTakeOwnership


ixClearPortArpTable

NAME - ixClearPortArpTableixClearPortArpTable - clears the arp table on an individual port

SYNOPSIS ixClearPortArpTable chassisID cardID portID

DESCRIPTION The ixClearPortArpTable command clears the arp table on a single port.

ARGUMENTS




RETURNS



EXAMPLES package require IxTclHalset host galaxyixInitialize $host

set chas 1set card 1set port 1

if {[ixClearPortArpTable $chas $card $port] != 0} { ixPuts "Could not clear Arp table on $chas:$card:$port"}

SEE ALSO ixClearArpTable


ixClearPortStatsC

NAME - ixClearPortStatsixClearPortStats - zero all statistic counters on an individual port

SYNOPSIS ixClearPortStats chassisID cardID portID

DESCRIPTION The ixClearPortStats command clears all statistic counters on a single port.

ARGUMENTS




RETURNS





set chas 1set cardA 1set portA 1

if {[ixClearPortStats $chas $cardA $portA] != 0} { ixPuts "Could not clear time stamp for $chas:$cardA:$portA"}

SEE ALSO ixClearStats


ixClearStats

NAME - ixClearStatsixClearStats - zero all statistic counters on a group of ports simultaneously

SYNOPSIS ixClearStats portList

DESCRIPTION The ixClearStats command clears all statistic counters on a list of ports simulta-neously. This command must be called before the transmission of validation traffic is started so that the proper metrics can be calculated at the end of trans-mission.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS


1 Error; the command was delivered to the IxServer but it could not process the. message




# Four different port list formatsset portList1 [list $chas,$cardA,$portA]set portList2 [list $chas,$cardA,$portA $chas,$cardB,$portB]set portList3 [list [list $chas $cardA $portA] [list $chas $cardB $portB]]set portList4 [list [list $chas,$cardA,$portA] [list $chas,$cardB,$portB]]

map new -type one2onemap config -type one2onemap add $chas $cardA $portA $chas $cardB $portBmap add $chas $cardB $portB $chas $cardA $portA

# Try each of the formatsif {[ixClearStats portList1] != 0} {


ixClearStatsC

ixPuts "Could not clear time stamp for $portList1"}if {[ixClearStats portList2] != 0} { ixPuts "Could not clear time stamp for $portList2"}if {[ixClearStats portList3] != 0} { ixPuts "Could not clear time stamp for $portList3"}if {[ixClearStats portList4] != 0} { ixPuts "Could not clear time stamp for $portList4"}if {[ixClearStats one2oneArray] != 0} { ixPuts "Could not clear time stamp for $one2oneArray"}

SEE ALSO ixClearPortStats


ixClearTimeStamp

NAME - ixClearTimeStampixClearTimeStamp - synchronizes the timestamp value among all chassis

SYNOPSIS ixClearTimeStamp portList

DESCRIPTION The ixClearTimeStamp command sends a message to the IxServer to synchro-nize the timestamp on a group of chassis. This feature is useful for calculating latency on ports across chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








# Try each of the formatsif {[ixClearTimeStamp portList1] != 0} { ixPuts "Could not clear time stamp for $portList1"


ixClearTimeStampC

}if {[ixClearTimeStamp portList2] != 0} { ixPuts "Could not clear time stamp for $portList2"}if {[ixClearTimeStamp portList3] != 0} { ixPuts "Could not clear time stamp for $portList3"}if {[ixClearTimeStamp portList4] != 0} { ixPuts "Could not clear time stamp for $portList4"}if {[ixClearTimeStamp one2oneArray] != 0} { ixPuts "Could not clear time stamp for $one2oneArray"}

SEE ALSO


ixCollectStats

NAME - ixCollectStatsixCollectStats - collect a particular statistic on a group of ports

SYNOPSIS ixCollectStats rxList statName rxStats totalStats

DESCRIPTION The ixCollectStats command gathers the same specified statistic from a number of ports and places the results in a return array.

ARGUMENTS

rxList (By value) The list of ports in one of the following formats:


statName (By value or reference) The name of the statistic to poll. This has to match one of the standard options defined in the stat command.

rxStats (By reference) The array containing the returned statistics per port. Each ele-ment is accessed with three comma separated arguments corresponding to the chassis, card and port being accessed. E.g. $rxStats(1, 1, 1)

totalStats (By reference) The total of the values in RxStats.

RETURNS






set portList [list [list $chas $cardA $portA] [list $chas $cardB $portB]]

# Setup startmap new -type one2one


ixCollectStatsC

map config -type one2onemap add $chas $cardA $portA $chas $cardB $portBmap add $chas $cardB $portB $chas $cardA $portA



stream config -numFrames 200000stream set $chas $cardB $portB 1

# Set up the portsixWritePortsToHardware one2oneArrayafter 1000if {[ixCheckLinkState one2oneArray] != 0} { ixPuts "Link is not up" exit}

# Clear statistics before startingif {[ixClearStats portList] != 0} { ixPuts "Could not clear statistics on $portList"}


# Check if the both ports have stoppedixCheckTransmitDone portListixPuts "Ports stopped transmitting"

if {[ixCollectStats $portList framesSent myArray myTotal] != 0} { ixPuts "Could not collect statistics on $portList"}

ixPuts "Total number is $myTotal"

foreach p $portList { scan $p "%d %d %d" ch ca po ixPuts "Port $p is $myArray($ch,$ca,$po)"}

SEE ALSO


ixConnectToChassis

NAME - ixConnectToChassisixConnectToChassis - connects to a list of chassis

SYNOPSIS ixConnectToChassis chassisList [cableLength]

DESCRIPTION The ixConnectToChassis command is called from ixInitialize. It connects to a list of chassis given the hostnames or IP addresses.

ARGUMENTS

chassisList (By value) The list of chassis hostnames or IP addresses, called by value.

cableLength (By value) (Optional) The length of the sync cable that connects the chain of chassis. Valid values are:

RETURNS

0 No Error, connection was established with the IxServer.

1 Error connecting to IxServer; possible causes are invalid hostname or IP address for chassis, IxServer not running on the chassis, or other network problem.

2 Version mismatch.

3 Timeout connecting to chassis; possible causes are invalid hostname or IP address for chassis, or IxServer not running on the chassis.


set host1 localhostset host2 galaxy

set ret [ixConnectToChassis $host1]switch $ret { 1 {ixPuts "Error connecting to chassis"} 2 {ixPuts "Version mismatch with chassis"} 3 {ixPuts "Timeout connecting to chassis"}}

Option Value Usage


cable6feet 1

cable9feet 2

cable12feet 3

cable15feet 4

cable18feet 5

cable21feet 6

cable24feet 7


ixConnectToChassisC


set pl [list $host1 $host2]set ret [ixConnectToChassis $pl 1]switch $ret { 1 {ixPuts "Error connecting to chassis"} 2 {ixPuts "Version mismatch with chassis"} 3 {ixPuts "Timeout connecting to chassis"}}


SEE ALSO ixDisconnectFromChassis, ixInitialize, ixProxyConnect


ixConnectToTclServer

NAME - ixConnectToTclServerixConnectToTclServer - connect a Unix client to a Tcl Server

SYNOPSIS ixConnectToTclServer serverName

DESCRIPTION The ixConnectToTclServer command connects a Tcl Client running on a non-Windows workstation to a Tcl Server running on a chassis or Windows-based system.

ARGUMENTS

serverName (By value) The name or IP address of the machine running the Tcl Server, called by value.

RETURNS


1 Error of any type.


set host galaxy

if {[ixConnectToTclServer $host] != 0} { ixPuts "Could not connect to Tcl Server on $host"}

ixDisconnectTclServer

SEE ALSO ixInitialize, ixProxyConnect


ixCreatePortListWildCardC

NAME - ixCreatePortListWildCardixCreatePortListWildCard - creates a port list using wildcard ‘*’ specification for cards and/or ports

SYNOPSIS ixCreatePortListWildCard portList [excludeList]

DESCRIPTION The ixCreatePortListWildCard command creates a list of ports in a sorted order based on the physical slots. Both arguments are passed by value. It accepts * as a wild card to indicate all cards or all ports on a card. A wild card cannot be used for chassis ID. Also, if a combination of a list element containing wild cards and port numbers is passed, then the port list passed MUST be in a sorted order, otherwise the some of those ports might not make it in the list.

ARGUMENTS



excludeList (By value) The list of ports to exclude in one of the following formats. No wild-cards may be used in this list:

One of the following literal strings, or a reference to a variable with the $ (e.g. $pl after set pl ...){{1 1 1}}{{1 1 1} {1 1 2} {1 1 3} {1 1 4}}

RETURNS A list of lists with the expanded port list.


set portList { {1 1 *} {1 * 2} }set excludeList { {1 1 1} {1 1 2} {1 2 2} }

set retList [ixCreatePortListWildCard $portList] ixPuts $retListset retList [ixCreatePortListWildCard $portList $excludeList]ixPuts $retList

SEE ALSO ixCreateSortedPortList


ixCreateSortedPortList

NAME - ixCreateSortedPortListixCreateSortedPortList - creates a port list for a range of ports, excluding spec-ified ports

SYNOPSIS ixCreateSortedPortList portFrom portTo excludeList

DESCRIPTION The ixCreateSortedPortList command creates a sorted list of ports based on the range of ports passed.

ARGUMENTS

portFrom (By value) The first port number. E.g. {1 1 1}.

portTo (By value) The last port number. E.g. {1 5 4}.

excludeList (By value) A list of lists containing individual ports to be excluded from the list. E.g. {{1 3 1} {1 3 2}}



set from {1 1 1}set to {1 2 1}set ex {{1 1 4}}

set retList [ixCreateSortedPortList $from $to $ex]ixPuts $retList

RETURNS A sorted list of lists with the expanded port list.

SEE ALSO ixCreatePortListWildCard


ixDisableArpResponseC

NAME - ixDisableArpResponseixDisableArpResponse - Disable ARP response on a set of ports

SYNOPSIS ixDisableArpResponse portList

DESCRIPTION The ixDisableArpResponse disables the ARP response engine for the set of ports.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








# Try each of the formatsif {[ixDisableArpResponse portList1] != 0} { ixPuts "Could not disable ARP response for $portList1"}if {[ixDisableArpResponse portList2] != 0} {


ixDisableArpResponse

ixPuts "Could not disable ARP response for $portList2"}if {[ixDisableArpResponse portList3] != 0} { ixPuts "Could not disable ARP response for $portList3"}if {[ixDisableArpResponse portList4] != 0} { ixPuts "Could not disable ARP response for $portList4"}if {[ixDisableArpResponse one2oneArray] != 0} { ixPuts "Could not disable ARP response for $one2oneArray"}

SEE ALSO ixDisablePortArpResponse, ixEnableArpResponse, ixEnablePortArpResponse


ixDisablePortArpResponseC

NAME - ixDisablePortArpResponseixDisablePortArpResponse - Disable ARP response on a single port

SYNOPSIS ixDisableArpResponse chassisID cardID portID [write]

DESCRIPTION The ixDisablePortArpResponse disables the ARP response engine for the port.

ARGUMENTS




write (By value) (Optional) Valid values:

write – the action will be committed to hardwarenoWrite – the action will not be committed to hardware but just set in

IxHAL (default)

RETURNS





if {[ixDisablePortArpResponse $chas $card $port] != 0} { ixPuts "Could not disable ARP response on $chas:$card:$port"}

SEE ALSO ixDisableArpResponse, ixEnableArpResponse, ixEnablePortArpResponse



NAME - ixDisconnectFromChassisixDisconnectFromChassis - disconnects from all chassis connected

SYNOPSIS ixDisconnectFromChassis [chassis ...]

DESCRIPTION The ixDisconnectFromChassis command is called at the end of the script which will disconnect from all the chassis that were connected to in the begin-ning of the script. It will also free any memory allocated by the Tcl script by call-ing the cleanUp command.

ARGUMENTS

chassis (By value) (Optional) A variable number of chassis to disconnect from.

RETURNS

0 No Error, successfully disconnected.

EXAMPLES package require IxTclHalset host galaxyixConnectToChassis $host

if {[ixDisconnectFromChassis] != 0} { ixPuts "Could not disconnect from all chassis"}

SEE ALSO ixInitialize, ixConnectToChassis


ixDisconnectTclServerC

NAME - ixDisconnectTclServerixDisconnectTclServer - Disconnect a Unix client from a Tcl Server

SYNOPSIS ixDisconnectToTclServer serverName

DESCRIPTION The ixDisconnectTclServer command disconnects a Tcl Client running on a non-Windows workstation to a Tcl Server running on a chassis or Windows-based system.

ARGUMENTS

serverName (By value) This argument is no longer used, but must be present.

RETURNS

0 No Error, successfully disconnected

EXAMPLES See examples in ixConnectToTclServer.

SEE ALSO ixConnectToTclServer, ixInitialize


ixEnableArpResponse

NAME - ixEnableArpResponseixEnableArpResponse - enable ARP response on a set of ports

SYNOPSIS ixEnableArpResponse mapType portList

DESCRIPTION The ixEnableArpResponse gets the MAC and IP address for a set of ports, sets up the address table and enables the ARP response engine for the set of ports. IP configuration must have been performed for this command to succeed.

ARGUMENTS

mapType (By value) The type of IP to MAC mapping to be used. One of:



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS






# For different port list formatsset portList1 [list $chas,$cardA,$portA]set portList2 [list $chas,$cardA,$portA $chas,$cardB,$portB]set portList3 [list [list $chas $cardA $portA] [list $chas $cardB $portB]]set portList4 [list [list $chas,$cardA,$portA] [list $chas,$cardB,$portB]]

Option Value Usage

oneIpToOneMAC 0 Each IP address is mapped to a single MAC address.

manyIpToOneMAC 1 All the IP addresses for a port are mapped to a single MAC address.


ixEnableArpResponseC


ip setDefaultip set 1 1 1ip set 1 1 2

# Try each of the formatsif {[ixEnableArpResponse oneIpToOneMAC portList1] != 0} { ixPuts "Could not enable ARP response for $portList1"}if {[ixEnableArpResponse oneIpToOneMAC portList2] != 0} { ixPuts "Could not enable ARP response for $portList2"}if {[ixEnableArpResponse manyIpToOneMAC portList3] != 0} { ixPuts "Could not enable ARP response for $portList3"}if {[ixEnableArpResponse manyIpToOneMAC portList4] != 0} { ixPuts "Could not enable ARP response for $portList4"}if {[ixEnableArpResponse manyIpToOneMAC one2oneArray] != 0} { ixPuts "Could not enable ARP response for $one2oneArray"}

SEE ALSO ixDisableArpResponse, ixDisablePortArpResponse, ixEnablePortArpResponse


ixEnablePortArpResponse

NAME - ixEnablePortArpResponseixEnablePortArpResponse - enable ARP response on a single port

SYNOPSIS ixEnableArpResponse mapType chassisID cardID portID [write]

DESCRIPTION The ixEnablePortArpResponse gets the MAC and IP address for a single port, sets up the address table and enables the ARP response engine for the port. IP configuration must have been performed for this command to succeed.

ARGUMENTS

mapType (By value) The type of IP to MAC mapping to be used. One of:






IxHAL (default)

RETURNS





ip setDefaultip set $chas $cardA $portA

if {[ixEnablePortArpResponse $::oneIpToOneMAC $chas $cardA $portA] != 0} { ixPuts "Could not enable ARP response for $chas:$cardA:$portA"

Option Value Usage

oneIpToOneMAC 0 Each IP address is mapped to a single MAC address.

manyIpToOneMAC 1 All the IP addresses for a port are mapped to a single MAC address.


ixEnablePortArpResponseC

}

SEE ALSO ixDisableArpResponse, ixDisablePortArpResponse, ixEnableArpResponse


ixGetChassisID

NAME - ixGetChassisIDixGetChassisID - get the ID of a chassis given its name

SYNOPSIS ixGetChassisID chassisName

DESCRIPTION The ixGetChassisID command gets the ID number assigned to a chassis in the chain.

ARGUMENTS

chassisName (By value) The hostname or IP address of chassis.

RETURNS

-1 The chassisName could not be found.

chassisID The ID number that was assigned to this chassis when a connection to the IxServer was made.


set chas [ixGetChassisID $host]if {$chas < 0} { ixPuts "Could not get chassis ID for $host"} else { ixPuts "Chassis ID for $host is $chas"}

SEE ALSO ixInitialize, ixConnectToChassis


ixInitializeC

NAME - ixInitializeixInitialize - connects to a list of chassis, to Tcl Servers for Unix clients and opens log file

SYNOPSIS ixInitialize chassisList [cableLen] [logfilename] [client]

DESCRIPTION If this command is executed on a Unix machine or the client argument is “tclCli-ent”, then ixInitialize will establish a Tcl Server connection with the first of the chassis in chassisList. Use ixConnectToTclServer and ixConnectToChassis if the Tcl Server is on some other host.

IxInitialize then establishes connection with IxServer running on a list of chassis and assigns chassis ID numbers to the chassis in the chain. The ID numbers will be assigned in incrementing order.

In addition, it will open a log file for the script. This command should be the first one in the script file after the package require IxTclHal.

ARGUMENTS

chassisList (By value) List of hostname or IP address of chassis in the chain to be connected to.

cableLen (By value) The length of the sync cable that connects the chain of chassis (Optional). Valid values are:

logfilename (By value) Name of the log file that will be created to store all log messages while the script is running. (Optional; default = NULL)

client (By value) The name of the client. (Optional; default = local)

RETURNS



2 Version mismatch.

Option Value Usage

cable3feet 0


cable9feet 2

cable12feet 3

cable15feet 4

cable18feet 5

cable21feet 6

cable24feet 7


ixInitialize


5 Could not make a Tcl Server connection to the first chassis in the chassisList.


set host1 localhostset host2 galaxy

set ret [ixInitialize $host1]switch $ret { 1 {ixPuts "Error connecting to chassis"} 2 {ixPuts "Version mismatch with chassis"} 3 {ixPuts "Timeout connecting to chassis"} 5 {ixPuts "Could not connect to Tcl Server"}}ixDisconnectFromChassis

set pl [list $host1 $host2]set ret [ixInitialize $pl 1]switch $ret { 1 {ixPuts "Error connecting to chassis"} 2 {ixPuts "Version mismatch with chassis"} 3 {ixPuts "Timeout connecting to chassis"} 5 {ixPuts "Could not connect to Tcl Server"}}


SEE ALSO ixConnectToChassis, ixDisconnectTclServer, ixProxyConnect


ixIsArpInstalledC

NAME - ixIsArpInstalledixIsArpInstalled - check if the optional ARP package is installed

SYNOPSIS ixIsArpInstalled

DESCRIPTION The ixIsArpInstalled command returns 0 or 1, depending on whether the ARP package is installed or not.

ARGUMENTS

None

RETURNS

true The ARP package is installed.

false The ARP package is not installed.

EXAMPLES Check to see whether ARP is installed:


set hostname localhostixInitialize $hostname

if {[isArpInstalled]} { ixPuts "Arp is installed"} else { ixPuts "Arp is not installed"}

SEE ALSO ixIsBgpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsIsisInstalled, ixIsRip-Installed, ixIsRsvpInstalled, ixUtils


ixIsBgpInstalled

NAME - ixIsBgpInstalledixIsBgpInstalled - check if the optional BGP package is installed

SYNOPSIS ixIsBgpInstalled

DESCRIPTION The ixIsBgpInstalled command returns 0 or 1, depending on whether the BGP package is installed or not.

ARGUMENTS

None

RETURNS

true The BGP package is installed.

false The BGP package is not installed.

EXAMPLES Check to see whether BGP is installed:



if {[isBgpInstalled]} { ixPuts "Bgp is installed"} else { ixPuts "Bgp is not installed"}

SEE ALSO ixIsArpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsIsisInstalled, ixIsRipIn-stalled, ixIsRsvpInstalled, ixUtils


ixIsIgmpInstalledC

NAME - ixIsIgmpInstalledixIsIgmpInstalled - check if the optional IGMP package is installed

SYNOPSIS ixIsIgmpInstalled

DESCRIPTION The ixIsIgmpInstalled command returns 0 or 1, depending on whether the IGMP package is installed or not.

ARGUMENTS

None

RETURNS

true The IGMP package is installed.

false The IGMP package is not installed.

EXAMPLES Check to see whether IGMP is installed:



if {[isIgmpInstalled]} { ixPuts "Igmp is installed"} else { ixPuts "Igmp is not installed"}

SEE ALSO ixIsArpInstalled, ixIsBgpInstalled, ixIsIsisInstalled, ixIsIsisInstalled, ixIsRipIn-stalled, ixIsRsvpInstalled, ixUtils


ixIsIsisInstalled

NAME - ixIsIsisInstalledixIsIsisInstalled - check if the optional ISIS package is installed

SYNOPSIS ixIsIsisInstalled

DESCRIPTION The ixIsIsisInstalled command returns 0 or 1, depending on whether the ISIS package is installed or not.

ARGUMENTS

None

RETURNS

true The ISIS package is installed.

false The ISIS package is not installed.

EXAMPLES Check to see whether ISIS is installed:



if {[isIsisInstalled]} { ixPuts "Isis is installed"} else { ixPuts "Isis is not installed"}

SEE ALSO ixIsArpInstalled, ixIsBgpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsRip-Installed, ixIsRsvpInstalled, ixUtils


ixIsIsisInstalledC

NAME - ixIsIsisInstalledixIsIsisInstalled - check if the optional OSPF package is installed

SYNOPSIS ixIsIsisInstalled

DESCRIPTION The ixIsIsisInstalled command returns 0 or 1, depending on whether the OSPF package is installed or not.

ARGUMENTS

None

RETURNS

true The OSPF package is installed.

false The OSPF package is not installed.

EXAMPLES Check to see whether OSPF is installed:



if {[isIsisInstalled]} { ixPuts "Isis is installed"} else { ixPuts "Isis is not installed"}

SEE ALSO ixIsArpInstalled, ixIsBgpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsRip-Installed, ixIsRsvpInstalled, ixUtils


ixIsRipInstalled

NAME - ixIsRipInstalledixIsRipInstalled - check if the optional RIP package is installed

SYNOPSIS ixIsRipInstalled

DESCRIPTION The ixIsRipInstalled command returns 0 or 1, depending on whether the RIP package is installed or not.

ARGUMENTS

None

RETURNS

true The RIP package is installed.

false The RIP package is not installed.

EXAMPLES Check to see whether RIP is installed:



if {[isRipInstalled]} { ixPuts "Rip is installed"} else { ixPuts "Rip is not installed"}

SEE ALSO ixIsArpInstalled, ixIsBgpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsIsi-sInstalled, ixIsRsvpInstalled, ixUtils


ixIsRsvpInstalledC

NAME - ixIsRsvpInstalledixIsRsvpInstalled - check if the optional RSVP package is installed

SYNOPSIS ixIsRsvpInstalled

DESCRIPTION The ixIsRsvpInstalled command returns 0 or 1, depending on whether the RSVP package is installed or not.

ARGUMENTS

None

RETURNS

true The RSVP package is installed.

false The RSVP package is not installed.

EXAMPLES Check to see whether RSVP is installed:



if {[isRsvpInstalled]} { ixPuts "Rsvp is installed"} else { ixPuts "Rsvp is not installed"}

SEE ALSO ixIsArpInstalled, ixIsBgpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsIsi-sInstalled, ixIsRipInstalled, ixUtils


ixGetLineUtilization

NAME - ixGetLineUtilizationixGetLineUtilization – gets the line utilization in one of two formats

SYNOPSIS ixGetLineUtilization chasID cardID portID [rateType]

DESCRIPTION The ixGetLineUtilization command returns the line utilization either as a per-centage of the maximum value or it terms of frames per second.

ARGUMENTS




rateType (By value) The requested return format. One of:

RETURNS The value indicated by rateType.


set fps [ixGetLineUtilization 1 1 1 typeFpsRate]

SEE ALSO ixUtils

Option Value Usage

typePercentMaxRate 0 (default) Returns the composit percentage of the maximum rate.

typeFpsRate 1 Returns the frames per second rate.


ixLoginC

NAME - ixLoginixLogin - logs in the user

SYNOPSIS ixLogin ixiaUser

DESCRIPTION The ixLogin command logs in the user.

ARGUMENTS

ixiaUser (By value) The name of the user.

RETURNS




if {[ixLogin George] != 0} { ixPuts "Could not log you in"}

SEE ALSO ixLogout


ixLogout

NAME - ixLogoutixLogout - logs out the user

SYNOPSIS ixLogout

DESCRIPTION The ixLogout command logs out the user.

ARGUMENTS

None

RETURNS




if {[ixLogout] != 0} { ixPuts "Could not log you out"}

SEE ALSO ixLogin


ixPortClearOwnershipC

NAME - ixPortClearOwnershipixPortClearOwnership - clears ownership of a single port

SYNOPSIS ixPortClearOwnership chassisID cardID portID [takeType]

DESCRIPTION The ixPortClearOwnership command clears ownership of the specified port.

ARGUMENTS





force - take regardless of whether the port is owned by someone else

RETURNS





set $chas 1set $card 1set $port 1

if {[ixPortClearOwnership $chas $card $port] != 0} { ixPuts "Could not clear ownership for $chas:$card$port"}

if {[ixPortClearOwnership $chas $card $port force] != 0} { ixPuts "Could not clear ownership for $chas:$card$port"}

SEE ALSO ixPortTakeOwnership, ixClearOwnership, ixTakeOwnership


ixPortTakeOwnership

NAME - ixPortTakeOwnershipixPortTakeOwnership - takes ownership of a single port

SYNOPSIS ixPortTakeOwnership chassisID cardID portID [takeType]

DESCRIPTION The ixPortTakeOwnership command takes ownership of the specified port.

ARGUMENTS





force - take regardless of whether the port is owned by someone else

RETURNS



EXAMPLE package req IxTclHal


set $chas 1set $card 1set $port 1

if {[ixPortTakeOwnership $chas $card $port] != 0} { ixPuts "Could not take ownership for $chas:$card$port"}

if {[ixPortTakeOwnership $chas $card $port force] != 0} { ixPuts "Could not take ownership for $chas:$card$port"}

SEE ALSO ixPortClearOwnership, ixClearOwnership, ixTakeOwnership


ixProxyConnectC

NAME - ixProxyConnectixProxyConnect - connects to a list of chassis, to Tcl Servers for Unix clients and opens log file

SYNOPSIS ixProxyConnect tclSrv chassisList [cableLen] [logfilename]

DESCRIPTION The ixProxyConnect command establishes connection with IxServer running on a list of chassis and will assign chassis ID numbers to the chassis in the chain. The ID numbers will be assigned in incrementing order to the master and slave chassis with the master chassis given ID 1. The command will also connect to the Tcl Server on the specified host. Also, it will open a log file for the script.

ARGUMENTS

tclSrv (By value) The hostname of the computer running the TclServer.

chassisList (By value) List of hostname or IP address of chassis in the chain to be connected to.

cableLen (By value) The length of the sync cable that connects the chain of chassis (Optional). Valid values are:

logfilename (By value) Name of the log file that will be created to store all log messages while the script is running. (Optional; default = NULL)

RETURNS



2 Version mismatch.


5 Could not make a Tcl Server connection to tclSrv.

Option Value Usage


cable6feet 1

cable9feet 2

cable12feet 3

cable15feet 4

cable18feet 5

cable21feet 6

cable24feet 7


ixProxyConnect


set host1 localhostset host2 galaxyset tclServer galaxy

set ret [ixProxyConnect $tclServer $host1]switch $ret { 1 {ixPuts "Error connecting to chassis"} 2 {ixPuts "Version mismatch with chassis"} 3 {ixPuts "Timeout connecting to chassis"} 5 {ixPuts "Could not connect to Tcl Server"}}ixDisconnectFromChassisixDisconnectTclServer

set pl [list $host1 $host2]set ret [ixProxyConnect $tclServer $pl $::cable6feet]switch $ret { 1 {ixPuts "Error connecting to chassis"} 2 {ixPuts "Version mismatch with chassis"} 3 {ixPuts "Timeout connecting to chassis"} 5 {ixPuts "Could not connect to Tcl Server"}}

ixDisconnectFromChassisixDisconnectTclServer

SEE ALSO ixConnectToChassis, ixInitialize, ixConnectToTclServer, ixDisconnectTclServer


ixPutsC

NAME - ixPutsixPuts - output text to the console.

SYNOPSIS ixPuts [-nonewline] arg...

DESCRIPTION The ixPuts command outputs its arguments to the console window with or with-out a newline.

ARGUMENTS

-nonewline If present, suppresses a newline at the end of the output.

arg ... Arguments which are concatenated together and displayed on the console.

RETURNS



EXAMPLE package require IxTclHal

ixPuts "hello"ixPuts -nonewline "This will "ixPuts -nonewline "all be displayed "ixPuts "on the same line"

SEE ALSO logMsg


ixResetPortSequenceIndex

NAME - ixResetPortSequenceIndexixResetPortSequenceIndex - reset a port’s sequence index

SYNOPSIS ixResetPortSequenceIndex chassisID cardID portID

DESCRIPTION The ixResetPortSequenceIndex command sends a message to the IxServer to reset the sequence number associated with a port.

ARGUMENTS




RETURNS



EXAMPLES package require IxTclHalset host galaxyixConnectToChassis $host


if {[ixResetPortSequenceIndex $chas $cardA $portA] != 0} { ixPuts "Could not reset port sequence index for $chas:$cardA:$portA"}

SEE ALSO ixResetSequenceIndex


ixResetSequenceIndexC

NAME - ixResetSequenceIndexixResetSequenceIndex - reset a group of ports’ sequence index

SYNOPSIS ixResetSequenceIndex portList

DESCRIPTION The ixResetSequenceIndex command sends a message to the IxServer to reset the sequence index associated with a group of ports.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








# Try each of the formatsif {[ixResetSequenceIndex portList1] != 0} { ixPuts "Could not reset sequence index for $portList1"}if {[ixResetSequenceIndex portList2] != 0} {


ixResetSequenceIndex

ixPuts "Could not reset sequence index for $portList2"}if {[ixResetSequenceIndex portList3] != 0} { ixPuts "Could not reset sequence index for $portList3"}if {[ixResetSequenceIndex portList4] != 0} { ixPuts "Could not reset sequence index for $portList4"}if {[ixResetSequenceIndex one2oneArray] != 0} { ixPuts "Could not reset sequence index for $one2oneArray"}

SEE ALSO ixResetPortSequenceIndex


ixSetCaptureModeC

NAME - ixSetCaptureModeixSetCaptureMode - set a group of ports to Capture Receive mode

SYNOPSIS ixSetCaptureMode portList [write]

DESCRIPTION The ixSetCaptureMode command sends a message to the IxServer to set the receive mode of a group of ports simultaneously to Capture mode. The ports may span over multiple chassis. This mode must be used when traffic is to be captured in the capture buffer. This mode is mutually exclusive with the Packet Group receive mode.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}



IxHAL (default)

RETURNS






set pl1 [list 1,$cardA,$portA]set pl2 [list 1,$cardA,$portA 1,$cardB,$portB]set pl3 [list [list $chas $cardA $portA] [list 1 $cardB $portB]]set pl4 [list [list 1,$cardA,$portA] [list 1,$cardB,$portB]]

map new -type one2onemap config -type one2onemap add 1 $cardA $portA 1 $cardB $portB


ixSetCaptureMode

map add 1 $cardB $portB 1 $cardA $portA

if {[ixSetCaptureMode pl1 write] != 0} { puts "Could not set capture mode for $pl1"}if {[ixSetCaptureMode pl2 write] != 0} { puts "Could not set capture mode for $pl2"}if {[ixSetCaptureMode pl3 write] != 0} { puts "Could not set capture mode for $pl3"}if {[ixSetCaptureMode pl4 write] != 0} { puts "Could not set capture mode for $pl4"}if {[ixSetCaptureMode one2oneArray write] != 0} { puts "Could not set capture mode for $one2oneArray"}

SEE ALSO ixSetPortCaptureMode


ixSetPacketFlowModeC

NAME - ixSetPacketFlowModeixSetPacketFlowMode - set a group of ports to Packet Flow Transmit mode

SYNOPSIS ixSetPacketFlowMode portList [write]

DESCRIPTION The ixSetPacketFlowMode command sends a message to the IxServer to set the transmit mode of a group of ports simultaneously to Packet Flow mode. The ports may span over multiple chassis. This mode is mutually exclusive with the Packet Streams transmit mode.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}



IxHAL (default)

RETURNS







map new -type one2onemap config -type one2onemap add 1 $cardA $portA 1 $cardB $portBmap add 1 $cardB $portB 1 $cardA $portA


ixSetPacketFlowMode

if {[ixSetPacketFlowMode pl1 write] != 0} { puts "Could not set PacketFlow mode for $pl1"}if {[ixSetPacketFlowMode pl2 write] != 0} { puts "Could not set PacketFlow mode for $pl2"}if {[ixSetPacketFlowMode pl3 write] != 0} { puts "Could not set PacketFlow mode for $pl3"}if {[ixSetPacketFlowMode pl4 write] != 0} { puts "Could not set PacketFlow mode for $pl4"}if {[ixSetPacketFlowMode one2oneArray write] != 0} { puts "Could not set PacketFlow mode for $one2oneArray"}

SEE ALSO ixSetPortPacketFlowMode, ixSetPacketStreamMode, ixSetPortPacketStream-Mode


ixSetPacketGroupModeC

NAME - ixSetPacketGroupModeixSetPacketGroupMode - set a group of ports to Packet Group Receive mode

SYNOPSIS ixSetPacketGroupMode portList [write]

DESCRIPTION The ixSetPacketGroupMode command sends a message to the IxServer to set the receive mode of a group of ports simultaneously to Packet Group mode. The ports may span over multiple chassis. This mode must be used when real-time latency metrics are to be obtained.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}



IxHAL (default)

RETURNS









ixSetPacketGroupMode

if {[ixSetPacketGroupMode pl1 write] != 0} { puts "Could not set PacketGroup mode for $pl1"}if {[ixSetPacketGroupMode pl2 write] != 0} { puts "Could not set PacketGroup mode for $pl2"}if {[ixSetPacketGroupMode pl3 write] != 0} { puts "Could not set PacketGroup mode for $pl3"}if {[ixSetPacketGroupMode pl4 write] != 0} { puts "Could not set PacketGroup mode for $pl4"}if {[ixSetPacketGroupMode one2oneArray write] != 0} { puts "Could not set PacketGroup mode for $one2oneArray"}

SEE ALSO ixSetPortPacketGroupMode


ixSetPacketStreamModeC

NAME - ixSetPacketStreamModeixSetPacketStreamMode - set a group of ports to Packet Stream Transmit mode

SYNOPSIS ixSetPacketStreamMode portList [write]

DESCRIPTION The ixSetPacketStreamMode command sends a message to the IxServer to set the transmit mode of a group of ports simultaneously to Packet Stream mode. The ports may span over multiple chassis. This mode is mutually exclusive with the Packet Flow transmit mode.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}



IxHAL

RETURNS









ixSetPacketStreamMode

if {[ixSetPacketStreamMode pl1 write] != 0} { puts "Could not set PacketStream mode for $pl1"}if {[ixSetPacketStreamMode pl2 write] != 0} { puts "Could not set PacketStream mode for $pl2"}if {[ixSetPacketStreamMode pl3 write] != 0} { puts "Could not set PacketStream mode for $pl3"}if {[ixSetPacketStreamMode pl4 write] != 0} { puts "Could not set PacketStream mode for $pl4"}if {[ixSetPacketStreamMode one2oneArray write] != 0} { puts "Could not set PacketStream mode for $one2oneArray"}

SEE ALSO ixSetPortPacketStreamMode


ixSetPortCaptureModeC

NAME - ixSetPortCaptureModeixSetPortCaptureMode - set a port to capture mode

SYNOPSIS ixSetPortCaptureMode chassisID cardID portID [write]

DESCRIPTION The ixSetPortCaptureMode command sends a message to the IxServer to set the receive mode of a single port to Capture mode. This mode must be used when traffic is to be captured in the capture buffer. This mode is mutually exclu-sive with the Packet Group receive mode.

ARGUMENTS






IxHAL (default)

RETURNS






if {[ixSetPortCaptureMode $chas $card $port write] != 0} { ixPuts "Could not set port $chas:$card:$port to capture mode"}

SEE ALSO ixSetCaptureMode


ixSetPortPacketFlowMode

NAME - ixSetPortPacketFlowModeixSetPortPacketFlowMode - set a port to Packet Flow Transmit mode

SYNOPSIS ixSetPortPacketFlowMode chassisID cardID portID [write]

DESCRIPTION The ixSetPortPacketFlowMode command sends a message to the IxServer to set the transmit mode of a single port to Packet Flow mode. This mode is mutu-ally exclusive with the Packet Streams transmit mode.

ARGUMENTS






IxHAL (default)

RETURNS






if {[ixSetPortPacketFlowMode $chas $card $port write] != 0} { ixPuts "Could not set port $chas:$card:$port to PacketFlow mode"}

SEE ALSO ixSetPacketFlowMode


ixSetPortPacketGroupModeC

NAME - ixSetPortPacketGroupModeixSetPortPacketGroupMode - set a port to Packet Group Receive mode

SYNOPSIS ixSetPortPacketGroupMode chassisID cardID portID [write]

DESCRIPTION The ixSetPortPacketGroupMode command sends a message to the IxServer to set the receive mode of a single port to Packet Group mode. This mode must be used when real-time latency metrics are to be obtained.

ARGUMENTS

chassisID (By value) The ID number of the chassis

cardID (By value) The ID number of the card

portID (By value) The ID number of the port



IxHAL (default)

RETURNS






if {[ixSetPortPacketGroupMode $chas $card $port write] != 0} { ixPuts "Could not set port $chas:$card:$port to PacketGroup mode"}

SEE ALSO ixSetPortPacketGroupMode


ixSetPortPacketStreamMode

NAME - ixSetPortPacketStreamModeixSetPortPacketStreamMode - set a port to Packet Stream Transmit mode

SYNOPSIS ixSetPortPacketStreamMode chassisID cardID portID [write]

DESCRIPTION The ixSetPortPacketStreamMode command sends a message to the IxServer to set the transmit mode of a single port to Packet Stream mode. This mode is mutually exclusive with the Packet Flow transmit mode.

ARGUMENTS






IxHAL (default)

RETURNS






if {[ixSetPortPacketStreamMode $chas $card $port write] != 0} { ixPuts "Could not set port $chas:$card:$port to PacketStream mode"}

SEE ALSO ixSetPacketStreamMode, ixSetPacketFlowMode, ixSetPortPacketFlowMode


ixSetPortTcpRoundTripFlowModeC

NAME - ixSetPortTcpRoundTripFlowModeixSetPortTcpRoundTripFlowMode - set a port to TCP Round Trip Flow mode

SYNOPSIS ixSetPortTcpRoundTripFlowMode chassisID cardID portID [write]

DESCRIPTION The ixSetPortTcpRoundTripFlowMode command sends a message to the IxServer to set the transmit mode of a single port to TCP Round Trip Flow mode.

ARGUMENTS






IxHAL (default)

RETURNS






if {[ixSetPortTcpRoundTripFlowMode $chas $card $port write] != 0} { ixPuts "Could not set port $chas:$card:$port to TcpRoundTripFlow mode"}

SEE ALSO ixSetTcpRoundTripFlowMode


ixSetTcpRoundTripFlowMode

NAME - ixSetTcpRoundTripFlowModeixSetTcpRoundTripFlowMode - set a group of ports to TCP Round Trip Flow mode

SYNOPSIS ixSetTcpRoundTripFlowMode portList [write]

DESCRIPTION The ixSetTcpRoundTripFlowMode command sends a message to the IxServer to set the flow mode of a group of ports simultaneously to TCP Round Trip mode. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}



IxHAL (default)

RETURNS









ixSetTcpRoundTripFlowModeC

if {[ixSetTcpRoundTripFlowMode pl1 write] != 0} { puts "Could not set PacketFlowMode for $pl1"}if {[ixSetTcpRoundTripFlowMode pl2 write] != 0} { puts "Could not set PacketFlowMode for $pl2"}if {[ixSetTcpRoundTripFlowMode pl3 write] != 0} { puts "Could not set PacketFlowMode for $pl3"}if {[ixSetTcpRoundTripFlowMode pl4 write] != 0} { puts "Could not set PacketFlowMode for $pl4"}if {[ixSetTcpRoundTripFlowMode one2oneArray write] != 0} { puts "Could not set PacketFlowMode for $one2oneArray"}

SEE ALSO ixSetPortTcpRoundTripFlowMode


ixSource

NAME - ixSourceixSource - recursive source

SYNOPSIS ixSource dirFileName

DESCRIPTION The ixSource command sources all the files in a particular directory and if there are sub-directories under the directory that are passed as an argument, it will source all the files under that sub-directory as well.

ARGUMENTS

dirFileName (By value) Any number of files to be sourced or a directory name where all the files under that directory are going to be sourced.

RETURNS

None

EXAMPLES ixSource test.tclixSource "c:/myTclProgs"

SEE ALSO


ixStartBGP4C

NAME - ixStartBGP4ixStartBGP4 - start BGP4 on a group of ports simultaneously

SYNOPSIS ixStartBGP4 portList

DESCRIPTION The ixStartBGP4 command sends a message to the IxServer to start Protocol Server BGP4 operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStartBGP4 pl1] != 0} { puts "Could not start BGP4 for $pl1"}if {[ixStartBGP4 pl2] != 0} { puts "Could not start BGP4 for $pl2"}


ixStartBGP4

if {[ixStartBGP4 pl3] != 0} { puts "Could not start BGP4 for $pl3"}if {[ixStartBGP4 pl4] != 0} { puts "Could not start BGP4 for $pl4"}if {[ixStartBGP4 one2oneArray] != 0} { puts "Could not start BGP4 for $one2oneArray"}

SEE ALSO ixStopBGP4


ixStartCaptureC

NAME - ixStartCaptureixStartCapture - start capture on a group of ports simultaneously

SYNOPSIS ixStartCapture portList

DESCRIPTION The ixStartCapture command sends a message to the IxServer to start capture on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








ixWritePortsToHardware one2oneArrayafter 1000


ixStartCapture

if {[ixCheckLinkState one2oneArray] != 0} { ixPuts "Link is not up"}

if {[ixStartCapture portList1] != 0} { ixPuts "Could not start capture on $portList1"}if {[ixStartCapture portList2] != 0} { ixPuts "Could not start capture on $portList2"}if {[ixStartCapture portList3] != 0} { ixPuts "Could not start capture on $portList3"}if {[ixStartCapture portList4] != 0} { ixPuts "Could not start capture on $portList4"}if {[ixStartCapture one2oneArray] != 0} { ixPuts "Could not start capture on $one2oneArray"}


SEE ALSO ixStartPortCapture, ixStopCapture, ixStopPortCapture


ixStartCollisionsC

NAME - ixStartCollisionsixStartCollisions - start collision on a group of ports simultaneously

SYNOPSIS ixStartCollisions portList

DESCRIPTION The ixStartCollisions command sends a message to the IxServer to start colli-sions on a group of ports simultaneously. The ports may span over multiple chassis. The ports must have been previously set-up for collisions via the force-Collisions command.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS





# Set up mappingmap new -type one2onemap config -type one2onemap add $chas $cardA $portA $chas $cardB $portBmap add $chas $cardB $portB $chas $cardA $portA

# Set up ports to 10Mbps and half duplexport setDefault port config -autonegotiate falseport config -duplex halfport config -speed 10port set $chas $cardA $portAport set $chas $cardB $portB

# Configure forced collisionsforcedCollisions setDefault


ixStartCollisions

forcedCollisions config -enable 1forcedCollisions config -consecutiveNonCollidingPackets 9forcedCollisions set 1 $cardA $portA forcedCollisions set 1 $cardB $portB

# Configure the streams to transmit at 50%stream setDefaultstream config -percentPacketRate 50stream config -rateMode usePercentRatestream set $chas $cardA $portA 1stream set $chas $cardB $portB 1


ixPuts "Starting Transmit.."ixStartStaggeredTransmit one2oneArray

ixPuts "Sleeping for 5 seconds"after 5000

ixPuts "Awake. Now going to attempt to start collisions"

if {[ixStartCollisions ::one2oneArray] != 0} { ixPuts "Could not start collisions on $::one2oneArray"}

SEE ALSO ixStartPortCollisions, ixStopCollisions, ixStopPortCollisions


ixStartIsisC

NAME - ixStartIsisixStartIsis - start ISIS on a group of ports simultaneously

SYNOPSIS ixStartIsis portList

DESCRIPTION The ixStartIsis command sends a message to the IxServer to start Protocol Server ISIS operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStartIsis pl1] != 0} { puts "Could not start Isis for $pl1"}if {[ixStartIsis pl2] != 0} { puts "Could not start Isis for $pl2"}


ixStartIsis

if {[ixStartIsis pl3] != 0} { puts "Could not start Isis for $pl3"}if {[ixStartIsis pl4] != 0} { puts "Could not start Isis for $pl4"}if {[ixStartIsis one2oneArray] != 0} { puts "Could not start Isis for $one2oneArray"}

SEE ALSO ixStopIsis


ixStartOspfC

NAME - ixStartOspfixStartOspf - start OSPF on a group of ports simultaneously

SYNOPSIS ixStartOspf portList

DESCRIPTION The ixStartOspf command sends a message to the IxServer to start Protocol Server OSPF operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStartOspf pl1] != 0} { puts "Could not start Ospf for $pl1"}if {[ixStartOspf pl2] != 0} { puts "Could not start Ospf for $pl2"}


ixStartOspf

if {[ixStartOspf pl3] != 0} { puts "Could not start Ospf for $pl3"}if {[ixStartOspf pl4] != 0} { puts "Could not start Ospf for $pl4"}if {[ixStartOspf one2oneArray] != 0} { puts "Could not start Ospf for $one2oneArray"}

SEE ALSO ixStopOspf


ixStartPacketGroupsC

NAME - ixStartPacketGroupsixStartPacketGroups - start calculating real-time latency on a group of ports simultaneously

SYNOPSIS ixStartPacketGroups portList

DESCRIPTION The ixStartPacketGroups command sends a message to the IxServer to start calculating real-time latency metrics on a group of ports simultaneously. The minimum, maximum and average latencies will be calculated for each packet group ID (PGID). The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS






# Set up port for loopback and packet group modeport setDefault port config -loopback trueport config -receiveMode portPacketGroupport set $chas $card $port

# Set up packet group configurationpacketGroup setDefault packetGroup config -groupIdOffset 52packetGroup config -latencyControl cutThroughpacketGroup config -preambleSize 8packetGroup config -signature {08 71 18 05}packetGroup config -signatureOffset 48packetGroup setRx $chas $card $port


ixStartPacketGroups

# Configure fir (Frame Identification Record) for streamstream setDefault stream config -fir true

# Set UDF 1 to count up the packet groupudf setDefault udf config -enable trueudf config -continuousCount falseudf config -countertype c16udf config -initval {00 00}udf config -offset 52udf config -repeat 10udf config -updown uuuuudf set 1

# Write config to streamstream set $chas $card $port 1

# Set up packet group configurationpacketGroup setDefault packetGroup config -groupId 1packetGroup config -groupIdOffset 52packetGroup config -insertSignature truepacketGroup config -signature {08 71 18 05}packetGroup config -signatureOffset 48packetGroup setTx $chas $card $port 1

# Write config to hardware, error checking omitted for brevityixWritePortsToHardware portListafter 1000ixCheckLinkState portList

# Start packet group operationif {[ixStartPacketGroups portList] != 0} { ixPuts "Could not start packet groups on $portList"}

# And then transmitixStartTransmit portList

SEE ALSO ixStartPortPacketGroups, ixStopPortPacketGroups, ixStopPacketGroups


ixStartPortCaptureC

NAME - ixStartPortCaptureixStartPortCapture - start capture on an individual port

SYNOPSIS ixStartPortCapture chassisID cardID portID

DESCRIPTION The ixStartPortCapture command starts capture on a single port.

ARGUMENTS




RETURNS




set chas 1set card 1set port 1set portList [list [list $chas $card $port]]

# Set loopback on portport setDefault port config -loopback trueport set $chas $card $port

# Set up stream to defaultsstream setDefault stream set $chas $card $port 1

# Write config to hardware and check link state# Error checking omitted for brevityixWritePortsToHardware portListafter 1000ixCheckLinkState portList

ixStartPortTransmit $chas $card $portif {[ixStartPortCapture $chas $card $port] != 0} { ixPuts "Could not start port capture on $chas:$card:$port"}

SEE ALSO ixStartCapture, ixStopCapture, ixStopPortCapture


ixStartPortCollisions

NAME - ixStartPortCollisionsixStartPortCollisions - start collisions on an individual port

SYNOPSIS ixStartPortCollisions chassisID cardID portID

DESCRIPTION The ixStartPortCollisions command starts collisions on a single port.

ARGUMENTS




RETURNS





# Set up mapping arraymap new -type one2onemap config -type one2onemap add $chas $cardA $portA $chas $cardB $portBmap add $chas $cardB $portB $chas $cardA $portA


# Configure forced collisionsforcedCollisions setDefaultforcedCollisions config -enable 1forcedCollisions config -consecutiveNonCollidingPackets 9forcedCollisions set 1 $cardA $portA forcedCollisions set 1 $cardB $portB


ixStartPortCollisionsC



ixPuts "Starting Transmit.."ixStartStaggeredTransmit one2oneArray

ixPuts "Sleeping for 5 seconds"after 5000

ixPuts "Awake. Now going to attempt to start collisions"

if {[ixStartPortCollisions $chas $cardA $portA] != 0} { ixPuts "Could not start collisions on $chas:$card:$port"}

SEE ALSO ixStartCollisions, ixStopCollisions, ixStopPortCollisions


ixStartPortPacketGroups

NAME - ixStartPortPacketGroupsixStartPortPacketGroups - start packet group operations on an individual port

SYNOPSIS ixStartPortPacketGroups chassisID cardID portID

DESCRIPTION The ixStartPortPacketGroups command sends a message to the IxServer to start calculating real-time latency metrics on a single port. The minimum, maxi-mum and average latencies will be calculated for each packet group ID (PGID).

ARGUMENTS




RETURNS










ixStartPortPacketGroupsC





# Start packet group operationif {[ixStartPortPacketGroups $chas $card $port] != 0} { ixPuts "Could not start packet groups on $chas:$card:$port"}

# And then transmitixStartTransmit portList

SEE ALSO ixStartPacketGroups, ixStopPacketGroups, ixStopPortPacketGroups


ixStartPortTransmit

NAME - ixStartPortTransmitixStartPortTransmit - start transmission on an individual port

SYNOPSIS ixStartPortTransmit chassisID cardID portID

DESCRIPTION The ixStartPortTransmit command starts transmission on a single port.

ARGUMENTS




RETURNS





# Set loopback on portport setDefault port config -loopback trueport set $chas $card $port# Set up stream to defaultsstream setDefault stream set $chas $card $port 1

# Write config to hardware and check link state# Error checking omitted for brevityixWritePortsToHardware portListixCheckLinkState portList

if {[ixStartPortTransmit $chas $card $port] != $::TCL_OK} { ixPuts "Could not start port transmit on $chas:$card:$port"}after 1000if {[ixStopPortTransmit $chas $card $port] != $::TCL_OK} { ixPuts "Could not stop port transmit on $chas:$card:$port"}

SEE ALSO ixStartTransmit, ixStopTransmit, ixStopTransmit


ixStartRipC

NAME - ixStartRipixStartRip - start RIP on a group of ports simultaneously

SYNOPSIS ixStartRip portList

DESCRIPTION The ixStartRip command sends a message to the IxServer to start Protocol Server RIP operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStartRip pl1] != 0} { puts "Could not start Rip for $pl1"}if {[ixStartRip pl2] != 0} { puts "Could not start Rip for $pl2"}


ixStartRip

if {[ixStartRip pl3] != 0} { puts "Could not start Rip for $pl3"}if {[ixStartRip pl4] != 0} { puts "Could not start Rip for $pl4"}if {[ixStartRip one2oneArray] != 0} { puts "Could not start Rip for $one2oneArray"}

SEE ALSO ixStopRip


ixStartRsvpC

NAME - ixStartRsvpixStartRsvp - start RSVP on a group of ports simultaneously

SYNOPSIS ixStartRsvp portList

DESCRIPTION The ixStartRsvp command sends a message to the IxServer to start Protocol Server RSVP operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStartRsvp pl1] != 0} { puts "Could not start Rsvp for $pl1"}if {[ixStartRsvp pl2] != 0} { puts "Could not start Rsvp for $pl2"}


ixStartRsvp

if {[ixStartRsvp pl3] != 0} { puts "Could not start Rsvp for $pl3"}if {[ixStartRsvp pl4] != 0} { puts "Could not start Rsvp for $pl4"}if {[ixStartRsvp one2oneArray] != 0} { puts "Could not start Rsvp for $one2oneArray"}

SEE ALSO ixStopRsvp


ixStartStaggeredTransmitC

NAME - ixStartStaggeredTransmitixStartStaggeredTransmit - start transmission on a group of ports in sequence

SYNOPSIS ixStartStaggeredTransmit portList

DESCRIPTION The ixStartStaggeredTransmit command sends a message to the IxServer to start transmission on a group of ports in sequence. The ports may span over mul-tiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS





# Examples of four ways to make a port listset portList2 [list $chas,$cardA,$cardA $chas,$cardB,$portB]set portList3 [list [list $chas $cardA $cardA] [list $chas $cardB $portB]]set portList4 [list [list $chas,$cardA,$cardA] [list $chas,$cardB,$portB]]



ixWritePortsToHardware one2oneArray


ixStartStaggeredTransmit

if {[ixCheckLinkState one2oneArray] != 0} { ixPuts "Link is not up"}

if {[ixStartStaggeredTransmit portList2] != 0} { ixPuts "Could not start StaggeredTransmit on $portList2"}if {[ixStartStaggeredTransmit portList3] != 0} { ixPuts "Could not start StaggeredTransmit on $portList3"}if {[ixStartStaggeredTransmit portList4] != 0} { ixPuts "Could not start StaggeredTransmit on $portList4"}if {[ixStartStaggeredTransmit one2oneArray] != 0} { ixPuts "Could not start StaggeredTransmit on $one2oneArray"}

after 1000

SEE ALSO ixStartTransmit, ixStopTransmit, ixStartPortTransmit, ixStopPortTransmit


ixStartTransmitC

NAME - ixStartTransmitixStartTransmit - start transmission on a group of ports simultaneously

SYNOPSIS ixStartTransmit portList

DESCRIPTION The ixStartTransmit command sends a message to the IxServer to start trans-mission on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS









ixStartTransmit

ixWritePortsToHardware one2oneArrayif {[ixCheckLinkState one2oneArray] != 0} { ixPuts "Link is not up\n" exit}

if {[ixStartTransmit portList1] != 0} { ixPuts "Could not start Transmit on $portList1"}if {[ixStartTransmit portList2] != 0} { ixPuts "Could not start Transmit on $portList2"}if {[ixStartTransmit portList3] != 0} { ixPuts "Could not start Transmit on $portList3"}if {[ixStartTransmit portList4] != 0} { ixPuts "Could not start Transmit on $portList4"}if {[ixStartTransmit one2oneArray] != 0} { ixPuts "Could not start Transmit on $one2oneArray"}

after 1000

SEE ALSO ixStopTransmit, ixStartPortTransmit, ixStopPortTransmit


ixStopBGP4C

NAME - ixStopBGP4ixStopBGP4 - stop BGP4 on a group of ports simultaneously

SYNOPSIS ixStopBGP4 portList

DESCRIPTION The ixStopBGP4 command sends a message to the IxServer to stop Protocol Server BGP4 operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStopBGP4 pl1] != 0} { ixPuts "Could not start BGP4 for $pl1"}if {[ixStopBGP4 pl2] != 0} { ixPuts "Could not start BGP4 for $pl2"}


ixStopBGP4

if {[ixStopBGP4 pl3] != 0} { ixPuts "Could not start BGP4 for $pl3"}if {[ixStopBGP4 pl4] != 0} { ixPuts "Could not start BGP4 for $pl4"}if {[ixStopBGP4 one2oneArray] != 0} { ixPuts "Could not start BGP4 for $one2oneArray"}

SEE ALSO ixStartBGP4


ixStopCaptureC

NAME - ixStopCaptureixStopCapture - stop capture on a group of ports simultaneously

SYNOPSIS ixStopCapture portList

DESCRIPTION The ixStopCapture command sends a message to the IxServer to stop capture on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS







ixWritePortsToHardware one2oneArrayafter 1000if {[ixCheckLinkState one2oneArray] != 0} { ixPuts "Link is not up\n" exit}

if {[ixStartCapture one2oneArray] != 0} { ixPuts "Could not start capture on $one2oneArray"}


ixStopCapture


if {[ixStopCapture one2oneArray] != 0} { ixPuts "Could not stop capture on $one2oneArray"}

SEE ALSO ixStartCapture, ixStartPortCapture, ixStopPortCapture


ixStopCollisionsC

NAME - ixStopCollisionsixStopCollisions - stop collisions on a group of ports simultaneously

SYNOPSIS ixStopCollisions portList

DESCRIPTION The ixStopCollisions command sends a message to the IxServer to stop colli-sions on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS







# Configure forced collisionsforcedCollisions setDefaultforcedCollisions config -enable 1


ixStopCollisions

forcedCollisions config -consecutiveNonCollidingPackets 9forcedCollisions set 1 $cardA $portA forcedCollisions set 1 $cardB $portB



ixStartStaggeredTransmit one2oneArrayafter 1000ixStartCollisions one2oneArray

after 1000if {[ixStopCollisions one2oneArray] != 0} { ixPuts "Could not stop collisions on $one2oneArray"}

SEE ALSO ixStartCollisions, ixStartPortCollisions, ixStopPortCollisions


ixStopIsisC

NAME - ixStopIsisixStopIsis - stop ISIS on a group of ports simultaneously

SYNOPSIS ixStopIsis portList

DESCRIPTION The ixStopIsis command sends a message to the IxServer to stop Protocol Server ISIS operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStopIsis pl1] != 0} { ixPuts "Could not start Isis for $pl1"}if {[ixStopIsis pl2] != 0} { ixPuts "Could not start Isis for $pl2"}


ixStopIsis

if {[ixStopIsis pl3] != 0} { ixPuts "Could not start Isis for $pl3"}if {[ixStopIsis pl4] != 0} { ixPuts "Could not start Isis for $pl4"}if {[ixStopIsis one2oneArray] != 0} { ixPuts "Could not start Isis for $one2oneArray"}

SEE ALSO ixStartIsis


ixStopOspfC

NAME - ixStopOspfixStopOspf - stop OSPF on a group of ports simultaneously

SYNOPSIS ixStopOspf portList

DESCRIPTION The ixStopOspf command sends a message to the IxServer to stop Protocol Server OSPF operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStopOspf pl1] != 0} { ixPuts "Could not start Ospf for $pl1"}if {[ixStopOspf pl2] != 0} { ixPuts "Could not start Ospf for $pl2"}


ixStopOspf

if {[ixStopOspf pl3] != 0} { ixPuts "Could not start Ospf for $pl3"}if {[ixStopOspf pl4] != 0} { ixPuts "Could not start Ospf for $pl4"}if {[ixStopOspf one2oneArray] != 0} { ixPuts "Could not start Ospf for $one2oneArray"}

SEE ALSO ixStartOspf


ixStopPacketGroupsC

NAME - ixStopPacketGroupsixStopPacketGroups - stop calculating real-time latency on a group of ports simultaneously

SYNOPSIS ixStopPacketGroups portList

DESCRIPTION The ixStopPacketGroups command sends a message to the IxServer to stop calculating real-time latency metrics on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








# Configure fir (Frame Identification Record) for stream


ixStopPacketGroups

stream setDefault stream config -fir true





# Start packet group operationixStartPacketGroups portList

# And then transmitixStartTransmit portListafter 10000

if {[ixStopPacketGroups portList] != 0} { ixPuts "Can’t stop packet group operation on $portList"}

SEE ALSO ixStartPacketGroups, ixStartPortPacketGroups, ixStopPortPacketGroups


ixStopPortCaptureC

NAME - ixStopPortCaptureixStopPortCapture - stop capture on an individual port

SYNOPSIS ixStopPortCapture chassisID cardID portID [groupId] [create] [destroy]

DESCRIPTION The ixStopPortCapture command stops capture on a single port.

ARGUMENTS




groupId (By value) The group number to be used in the join message. If omitted, the default value of 101064 will be used.

create (By value) Create a new port group (create) or not (nocreate). (default = create)

destroy (By value) Clean up a created port group when command completes (destroy) or not (nodestroy). (default = destroy)

RETURNS







ixWritePortsToHardware one2oneArrayafter 1000if {[ixCheckLinkState one2oneArray] != 0} {


ixStopPortCapture

ixPuts "Link is not up"}

if {[ixStartCapture one2oneArray] != 0} { ixPuts "Could not start capture on $one2oneArray"}


if {[ixStopPortCapture $chas $cardA $portA] != 0} { ixPuts "Could not stop capture on $chas:$cardA:$portA"}if {[ixStopPortCapture $chas $cardB $portB] != 0} { ixPuts "Could not stop capture on $chas:$cardB:$portB"}

SEE ALSO ixStartCapture, ixStopCapture, ixStartPortCapture


ixStopPortCollisionsC

NAME - ixStopPortCollisionsixStopPortCollisions - stop collisions on an individual port

SYNOPSIS ixStopPortCollisions chassisID cardID portID

DESCRIPTION The ixStopPortCollisions command stops collisions on a single port.

ARGUMENTS




RETURNS







# Configure forced collisionsforcedCollisions setDefaultforcedCollisions config -enable 1forcedCollisions config -consecutiveNonCollidingPackets 9forcedCollisions set 1 $cardA $portA forcedCollisions set 1 $cardB $portB


ixStopPortCollisions



ixStartStaggeredTransmit one2oneArrayafter 1000ixStartCollisions ::one2oneArray

after 1000if {[ixStopPortCollisions $chas $cardA $portA] != 0} { ixPuts "Could not stop collisions on $chas:$cardA:$portA"}if {[ixStopPortCollisions $chas $cardB $portB] != 0} { ixPuts "Could not stop collisions on $chas:$cardB:$portB"}

SEE ALSO ixStartCollisions, ixStopCollisions, ixStartPortCollisions


ixStopPortPacketGroupsC

NAME - ixStopPortPacketGroupsixStopPortPacketGroups - stop packet group operations on an individual port

SYNOPSIS ixStopPortPacketGroups chassisID cardID portID

DESCRIPTION The ixStopPortPacketGroups command sends a message to the IxServer to stop calculating real-time latency metrics on a single port. The minimum, maxi-mum and average latencies will be calculated for each packet group ID (PGID).

ARGUMENTS




RETURNS










ixStopPortPacketGroups





# Start packet group operationixStartPortPacketGroups $chas $cardA $portAixStartPortPacketGroups $chas $cardB $portB

# And then transmitixStartTransmit portListafter 10000

if {[ixStopPortPacketGroups $chas $cardA $portA] != 0} { ixPuts "Can’t stop packet group operation on $chas:$cardA:$portA"}if {[ixStopPortPacketGroups $chas $cardB $portB] != 0} { ixPuts "Can’t stop packet group operation on $chas:$cardB:$portB"}

SEE ALSO ixStartPacketGroups, ixStopPacketGroups, ixStartPortPacketGroups


ixStopPortTransmitC

NAME - ixStopPortTransmitixStopPortTransmit - stop transmission on an individual port

SYNOPSIS ixStopPortTransmit chassisID cardID portID

DESCRIPTION The ixStopPortTransmit command stops transmission on a single port.

ARGUMENTS




RETURNS





# Set loopback on portport setDefault port config -loopback trueport set $chas $card $port# Set up stream to defaultsstream setDefault stream set $chas $card $port 1

# Write config to hardware and check link state# Error checking omitted for brevityixWritePortsToHardware portListafter 1000ixCheckLinkState portList

if {[ixStartPortTransmit $chas $card $port] != 0} { ixPuts "Could not start port transmit on $chas:$card:$port"}after 1000if {[ixStopPortTransmit $chas $card $port] != 0} { ixPuts "Could not stop port transmit on $chas:$card:$port"}

SEE ALSO ixStartTransmit, ixStopTransmit, ixStopPortTransmit


ixStopRip

NAME - ixStopRipixStopRip - stop RIP on a group of ports simultaneously

SYNOPSIS ixStopRip portList

DESCRIPTION The ixStopRip command sends a message to the IxServer to stop Protocol Server RIP operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStopRip pl1] != 0} { ixPuts "Could not start Rip for $pl1"}if {[ixStopRip pl2] != 0} { ixPuts "Could not start Rip for $pl2"}


ixStopRipC

if {[ixStopRip pl3] != 0} { ixPuts "Could not start Rip for $pl3"}if {[ixStopRip pl4] != 0} { ixPuts "Could not start Rip for $pl4"}if {[ixStopRip one2oneArray] != 0} { ixPuts "Could not start Rip for $one2oneArray"}

SEE ALSO ixStartRip


ixStopRsvp

NAME - ixStopRsvpixStopRsvp - stop RSVP on a group of ports simultaneously

SYNOPSIS ixStopRsvp portList

DESCRIPTION The ixStopRsvp command sends a message to the IxServer to stop Protocol Server RSVP operation on a group of ports simultaneously. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








if {[ixStopRsvp pl1] != 0} { ixPuts "Could not start Rsvp for $pl1"}if {[ixStopRsvp pl2] != 0} { ixPuts "Could not start Rsvp for $pl2"}


ixStopRsvpC

if {[ixStopRsvp pl3] != 0} { ixPuts "Could not start Rsvp for $pl3"}if {[ixStopRsvp pl4] != 0} { ixPuts "Could not start Rsvp for $pl4"}if {[ixStopRsvp one2oneArray] != 0} { ixPuts "Could not start Rsvp for $one2oneArray"}

SEE ALSO ixStartRsvp


ixStopTransmit

NAME - ixStopTransmitixStopTransmit - stop transmission on a group of ports simultaneously

SYNOPSIS ixStopTransmit portList

DESCRIPTION The ixStopTransmit command stops transmission on a single port.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








ixWritePortsToHardware one2oneArrayafter 1000if {[ixCheckLinkState one2oneArray] != 0} {


ixStopTransmitC

ixPuts "Link is not up"}

ixStartTransmit portList1after 5000if {[ixStopTransmit portList1] != 0} { ixPuts "Could not stop Transmit on $portList1"}ixStartTransmit portList2after 5000if {[ixStopTransmit portList2] != 0} { ixPuts "Could not stop Transmit on $portList2"}ixStartTransmit portList3after 5000if {[ixStopTransmit portList3] != 0} { ixPuts "Could not stop Transmit on $portList3"}ixStartTransmit portList4after 5000if {[ixStopTransmit portList4] != 0} { ixPuts "Could not stop Transmit on $portList4"}ixStartTransmit ::one2oneArrayafter 5000if {[ixStopTransmit one2oneArray] != 0} { ixPuts "Could not stop Transmit on $one2oneArray"}

SEE ALSO ixStopTransmit, ixStartPortTransmit, ixStopPortTransmit


ixTakeOwnership

NAME - ixTakeOwnershipixTakeOwnership - takes ownership of all the ports in the list

SYNOPSIS ixTakeOwnership portList [takeType]

DESCRIPTION The ixTakeOwnership command takes ownership of all the ports in the list.

ARGUMENTS




force – take regardless of whether the port is owned by someone elsenotForce – do not force ownership

RETURNS




set portsToOwn {{1 1 *} {1 2 1} {1 2 2}}ixTakeOwnership $portsToOwn force

SEE ALSO ixClearOwnership, ixPortClearOwnership, ixPortTakeOwnership


ixTransmitArpRequestC

NAME - ixTransmitArpRequestixTransmitArpRequest - transmit arp requests on a group of ports simulta-neously

SYNOPSIS ixTransmitArpRequest portList

DESCRIPTION The ixTransmitArpRequest command sends a message to the IxServer to start transmission of arp requests on a group of ports simultaneously using the proto-col server. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS








# Need to set up IP for ARP ip setDefault


ixTransmitArpRequest

ip set 1 1 1ip set 1 1 2

# Try each of the formatsif {[ixTransmitArpRequest portList1] != 0} { ixPuts "Could not transmit ARP request for $portList1\n"}if {[ixTransmitArpRequest portList2] != 0} { ixPuts "Could not transmit ARP request for $portList2\n"}if {[ixTransmitArpRequest portList3] != 0} { ixPuts "Could not transmit ARP request for $portList3\n"}if {[ixTransmitArpRequest portList4] != 0} { ixPuts "Could not transmit ARP request for $portList4\n"}if {[ixTransmitArpRequest one2oneArray] != 0} { ixPuts "Could not transmit ARP request for $one2oneArray\n"}

SEE ALSO ixTransmitPortArpRequest


ixTransmitIgmpJoinC

NAME - ixTransmitIgmpJoinixTransmitIgmpJoin - transmit IGMP membership report messages on a group of ports simultaneously

SYNOPSIS ixTransmitIgmpJoin portList [groupId] [create] [destroy]

DESCRIPTION The ixTransmitIgmpJoin command sends a message to the IxServer to start transmission of IGMP membership messages on a group of ports simultaneously using the protocol server. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

groupId (By value) The group number to be used in the join message. If omitted, the default value of 101064 will be used.



RETURNS







ixTransmitIgmpJoin



ip setDefaultip set $chas $cardA $portAip set $chas $cardB $portB


if {[ixTransmitIgmpJoin portList1] != 0} { ixPuts "Could not Transmit Igmp Join on $portList1"}if {[ixTransmitIgmpJoin portList2] != 0} { ixPuts "Could not Transmit Igmp Join on $portList2"}if {[ixTransmitIgmpJoin portList3] != 0} { ixPuts "Could not Transmit Igmp Join on $portList3"}if {[ixTransmitIgmpJoin portList4] != 0} { ixPuts "Could not Transmit Igmp Join on $portList4"}if {[ixTransmitIgmpJoin ::one2oneArray] != 0} { ixPuts "Could not Transmit Igmp Join on ::one2oneArray"}

SEE ALSO ixTransmitIgmpLeave


ixTransmitIgmpLeaveC

NAME - ixTransmitIgmpLeaveixTransmitIgmpLeave - transmit IGMP leave messages on a group of ports simultaneously

SYNOPSIS ixTransmitIgmpLeave portList [groupId] [create] [destroy]

DESCRIPTION The ixTransmitIgmpLeave command sends a message to the IxServer to start transmission of IGMP membership leave messages on a group of ports simulta-neously using the protocol server. The ports may span over multiple chassis.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

groupId (By value) The group number to be used in the leave message. If omitted, the default value of 101064 will be used.



RETURNS



EXAMPLE package require IxTclHalset host galaxyixInitialize $host




ixTransmitIgmpLeave



ip setDefaultip set $chas $cardA $portAip set $chas $cardB $portB


if {[ixTransmitIgmpLeave portList1] != 0} { ixPuts "Could not Transmit Igmp Leave on $portList1"}if {[ixTransmitIgmpLeave portList2] != 0} { ixPuts "Could not Transmit Igmp Leave on $portList2"}if {[ixTransmitIgmpLeave portList3] != 0} { ixPuts "Could not Transmit Igmp Leave on $portList3"}if {[ixTransmitIgmpLeave portList4] != 0} { ixPuts "Could not Transmit Igmp Leave on $portList4"}if {[ixTransmitIgmpLeave one2oneArray] != 0} { ixPuts "Could not Transmit Igmp Leave on one2oneArray"}

SEE ALSO ixTransmitIgmpJoin


ixTransmitPortArpRequestC

NAME - ixTransmitPortArpRequestixTransmitPortArpRequest - transmit arp requests on an individual port

SYNOPSIS ixTransmitPortArpRequest chassisID cardID portID

DESCRIPTION The ixTransmitPortArpRequest command sends a message to the IxServer to start transmission of arp requests on a single port using the protocol server.

ARGUMENTS

chassisID (By value) The ID number of the chassis

cardID (By value) The ID number of the card

portID (By value) The ID number of the port

RETURNS






# Need to set up IP for ARP ip setDefaultip set $chas $cardA $portAip set $chas $cardB $portB

if {[ixTransmitPortArpRequest $chas $cardA $portA] != 0} { ixPuts "Could not transmit ARP request for $chas:$cardA:$cardB"}if {[ixTransmitPortArpRequest $chas $cardB $portB] != 0} { ixPuts "Could not transmit ARP request for $chas:$cardB:$cardB"}

SEE ALSO ixTransmitArpRequest


ixUtils

NAME - ixUtilsixUtils - determine whether optional software components are installed

SYNOPSIS ixUtils sub-command

DESCRIPTION The ixUtils sub-commands allow for the determination whether optional soft-ware has been installed.

COMMANDS The ixUtils command is invoked with the following sub-commands. If no sub-command is specified, returns a list of all sub-commands available.

ixUtils getLineUtilization chasID cardID portID [rateType]This will return the line utilization in one or two forms, depending on the value of rateType:

ixUtils isArpInstalledDetermines whether the ARP optional package has been installed and returns a 1 (installed) or 0 (not installed).

ixUtils isBgpInstalledDetermines whether the BGP optional package has been installed and returns a 1 (installed) or 0 (not installed).

ixUtils isIgmpInstalledDetermines whether the IGMP optional package has been installed and returns a 1 (installed) or 0 (not installed).

ixUtils isIsisInstalledDetermines whether the ISIS optional package has been installed and returns a 1 (installed) or 0 (not installed).

ixUtils isOspfInstalledDetermines whether the OSPF optional package has been installed and returns a 1 (installed) or 0 (not installed).

ixUtils isRipInstalledDetermines whether the RIP optional package has been installed and returns a 1 (installed) or 0 (not installed).

ixUtils isRsvpInstalledDetermines whether the RSVP optional package has been installed and returns a 1 (installed) or 0 (not installed).

Option Value Usage

typePercentMaxRate 0 (default) Returns the composit percentage of the maximum rate.

typeFpsRate 1 Returns the frames per second rate.


ixUtilsC


set hostname galaxyixInitialize $hostname

if {[ixUtils isArpInstalled]} { ixPuts "Arp is installed"} else { ixPuts "Arp is not installed"}if {[ixUtils isBgpInstalled]} { ixPuts "Bgp is installed"} else { ixPuts "Bgp is not installed"}if {[ixUtils isIgmpInstalled]} { ixPuts "Igmp is installed"} else { ixPuts "Igmp is not installed"}if {[ixUtils isIsisInstalled]} { ixPuts "Isis is installed"} else { ixPuts "Isis is not installed"}if {[ixUtils isOspfInstalled]} { ixPuts "Ospf is installed"} else { ixPuts "Ospf is not installed"}if {[ixUtils isRipInstalled]} { ixPuts "Rip is installed"} else { ixPuts "Rip is not installed"}if {[ixUtils isRsvpInstalled]} { ixPuts "Rsvp is installed"} else { ixPuts "Rsvp is not installed"}

SEE ALSO ixIsArpInstalled, ixIsBgpInstalled, ixIsIgmpInstalled, ixIsIsisInstalled, ixIsIsi-sInstalled, ixIsRipInstalled, ixIsRsvpInstalled


ixWriteConfigToHardware

NAME - ixWriteConfigToHardwareixWriteConfigToHardware - writes streams, filters, protocol configuration on ports in hardware

SYNOPSIS ixWriteConfigToHardware portList

DESCRIPTION The ixWriteConfigToHardware command commits the configuration of streams, filters, and protocol information on a group of ports to hardware. This command is useful when a large number of ports are involved.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS









ixWriteConfigToHardwareC

if {[ixWriteConfigToHardware portList1] != 0} { ixPuts "Could not write config to $portList1"}if {[ixWriteConfigToHardware portList2] != 0} { ixPuts "Could not write config to $portList2"}if {[ixWriteConfigToHardware portList3] != 0} { ixPuts "Could not write config to $portList3"}if {[ixWriteConfigToHardware portList4] != 0} { ixPuts "Could not write config to $portList4"}if {[ixWriteConfigToHardware one2oneArray] != 0} { ixPuts "Could not write config to one2oneArray"}

SEE ALSO ixWritePortsToHardware


ixWritePortsToHardware

NAME - ixWritePortsToHardwareixWritePortsToHardware - writes port properties in hardware

SYNOPSIS ixWritePortsToHardware portList

DESCRIPTION The ixWritePortsToHardware command commits the configuration such as Mii properties on 10/100 interface (such as speed, duplex modes, autonegotia-tion), port properties on Gigabit interfaces, and PPP parameters on Packet over Sonet interfaces on a group of ports to hardware. It also performs all of the func-tions of ixWriteConfigToHardware. This command is useful when a large num-ber of ports are involved. Note, this command may result in a loss of link, depending on the changes that have been made.

ARGUMENTS



set pl {{1 1 1} {1 1 2} {1 1 3} {1 1 4}} -or-set pl {1,1,1 1,1,2 1,1,3 1,1,4}

RETURNS



EXAMPLES See the example under ixStartTransmit.

SEE ALSO ixWriteConfigToHardware


ixWritePortsToHardwareC


DAppendix D: Miscellaneous Unsupported Commands

Ixia Tcl Development Guide D-1

send_arp_framesD

NAME - send_arp_framessend_arp_frames - Sends an ARP to the DUT for IP learning

SYNOPSIS send_arp_frames arg

DESCRIPTION The send_arp_frames command accepts an array type created by the map com-mand. ARP frames are transmitted from all ports in the array at a rate specified by the learn command in order to allow the DUT to set up ARP table. Note that for some DUTs, setting up the ARP table may not be sufficient for setting the IP forwarding database; in this case, send_ipfastpath_frames should be used in conjunction with send_arp_frames. The ports may span over multiple chassis.

STANDARD OPTIONS None

COMMAND The send_arp_frames command is invoked with the following arguments.send_arp_frames one2oneArray

send_arp_frames one2manyArray

send_arp_frames many2oneArray

send_arp_frames many2manyArray

SEE ALSO map, learn, send_learn_frames, send_fastpath_frames

D-2 Ixia Tcl Development Guide

send_fastpath_frames

NAME - send_fastpath_framessend_fastpath_frames - Sends IP fast path frames after ARP

SYNOPSIS send_fastpath_frames mapArray

DESCRIPTION NOTE: This command has been phased out. However, it is still backward com-patible.The send_fastpath_frames command accepts an array type created by the map command. IP frames are transmitted from all ports in the array at a rate specified by the fastpath command in order to allow the DUT to set up the IP forwarding database, or fast path. The ports may span over multiple chassis.

COMMAND The send_fastpath_frames command is invoked with the following arguments.send_fastpath_frames one2oneArray

send_fastpath_frames one2manyArray

send_fastpath_frames many2oneArray

send_fastpath_frames many2manyArray

SEE ALSO map, learn


send_learn_framesD

NAME - send_learn_framessend_learn_frames - Sends MAC frames to the DUT for learning

SYNOPSIS send_learn_frames arg

DESCRIPTION The send_learn_frames command accepts an array type created by the map command. MAC frames are transmitted from all receive ports in the array at a rate specified by the learn command in order to allow the DUT to learn the MAC addresses. The ports may span over multiple chassis.


COMMAND The send_learn_frames command is invoked with the following arguments.send_learn_frames one2oneArray

send_learn_frames one2manyArray

send_learn_frames many2oneArray

send_learn_frames many2manyArray

SEE ALSO map, learn, send_arp_frames, send_fastpath_frames


send_ripx_frames

NAME - send_ripx_framessend_ripx_frames - Sends RIPX frames to the DUT for IPX learning

SYNOPSIS send_ripx_frames arg

DESCRIPTION The send_ripx_frames command accepts an array type created by the map com-mand. RIPX frames are transmitted from all ports in the array at a rate specified by the learn command in order to allow the DUT to learn the IPX network addresses and sockets. The ports may span over multiple chassis.


COMMAND The send_ripx_frames command is invoked with the following arguments.send_ripx_frames one2oneArray

send_ripx_frames one2manyArray

send_ripx_frames many2oneArray

send_ripx_frames many2manyArray

SEE ALSO map, learn, send_arp_frames, send_learn_frames


send_ripx_framesD


EScriptGenScriptGen is an auxiliary Tcl tool that is installed as part of the Tcl Client pack-age. It’s purpose is to create a Tcl program which reflects the configuration of a particular port. ScriptGen is run from a Wish Console and the resulting program is written to disk and shown in the console window. The configuration of the port may have been established through the use of any of the Ixia tools: IxExplorer, ScriptMate, TCL API or C++ API. ScriptGen runs both on Windows-based and Unix-based machines.

ScriptGen generates a complete Tcl program into an output file. All aspects of a port’s configuration is reflected in the output.

Invoking ScriptGen Windows

In order to use ScriptGen, use the Windows Start menu for the Ixia group, as shown in Figure E-1 on page E-1.

Figure E-1. Wish Console Icon

Appendix E: ScriptGen Usage

Ixia Tcl Development Guide E-1

ScriptGenE

Unix Systems

On Unix systems, the Wish Console must be used and is usually started by invok-ing wish in the Ixia/bin directory, then sourcing ixSgMain.tcl in the Ixia/scriptgen directory.

This will bring up a separate window, which should be used to invoke ScriptGen. This brings up the ScriptGen dialog shown in Figure E-2 on page E-2.

Figure E-2. ScriptGen Usage Dialog

The fields in this dialog are described in Table E-1 on page E-2.TABLE E-1. ScriptGen Usage Dialog Fields

Field Usage

go Starts the process of generating the output script based on the other settings in this dialog.

Output to File If checked, the output is saved to the file indicated in Output File Name. Output always goes to the Wish Console window.

Host Name The name of the chassis holding the port to be interpreted.

Output File Name The name of the output file to generate the output into. The name of the .tcl file should be changed for each port used.

Browse Used in conjunction with Output File Name to set the directory and file name to be used for output.

Card The number of the card holding the port to be interpreted.

Port The number of the port to be interpreted.

E-2 Ixia Tcl Development Guide

FTclServerThe Tcl Server is a software module which implements an intermediate process needed to support non-Windows (Unix) ScriptMate, Tcl and other clients. It may either reside on an Ixia chassis or on an intermediate Windows based system between the Unix system and the Ixia chassis. Figure F-1 on page F-1 illustrates the former case.

Figure F-1. Tcl Server on an Ixia Chassis

Appendix F: TclServer Usage

Unix Client

Tcl script

ScriptMate

Network Interface

Network

Ixia Chassis

IxServer

TclServer

TclHAL

Ixia Tcl Development Guide F-1

Installation and InvocationF

Figure F-2 on page F-2 illustrates the latter case.

Figure F-2. Tcl Server on an Independent Windows Host

This last case has the advantage that TclServer runs on a different processor than the chassis itself – allowing the chassis to run faster.

Installation and InvocationTcl Server is installed on an Ixia chassis or Windows host using the standard Ixia installation methods. See the Ixia Quick Start Guide for a further discussion. The Tcl Server is listed among the optional components.

When Tcl Server is installed, it is automatically included in the All Users Startup group so that the Tcl Server will automatically start up when any user logs in. If it is necessary to restart Tcl Server, then the icon which has been placed on the desktop can be used. The icon is shown below.

Unix Client

Tcl script

Tcl script

Network Interface

Network

Ixia Chassis

IxServer

TclHAL

Windows Host

TclServer

Network

F-2 Ixia Tcl Development Guide

Tcl Server Usage

Tcl Server UsageNormally Tcl Server requires no user interaction. In day-to-day usage, it may be safely minimized.

Several options, however, are available for troubleshooting. The initial Tcl Server screen, before any connections from any clients, is shown in Figure F-1 on page F-1.

Figure F-3. Initial Tcl Server Screen

The two lines in the main window indicate that the server is ‘listening’ for con-nections from clients on two ports:

• Port 4555–this is the default port used by ScriptMate and by Tcl programs which use the Ixia Tcl APIs. All standard connections will be visible in the tree beneath this node.

• Port 4500–this port is used internally by several Ixia products for rapid file transfer.

Connections are reflected within the tree once they have been made as shown in Figure F-4 on page F-3.

Figure F-4. Tcl Server with Connection


Tcl Server UsageF

The menus available in this window are:

Options The options available with Tcl Server available by selecting Tools..Options from the Tcl Server window. The dialog is shown in Figure F-5 on page F-4.

Figure F-5. IxTclServer Options

TABLE F-1. Tcl Server Menus

Menu Usage

File Contains a single ‘exit’ option.

Tcl Server Allows for the creation of additional ports on which Tcl Server will listen for connections. See Advance Usage on page F-5 for a further discussion.

Tcl Interpreter The Show option opens a separate window which displays the commands that are sent through Tcl Server as well as the results received from the chassis. The contents of this screen are controlled by the Tools..Options menu. This menu option is only active when a Tcl Server connection is selected. The same window may be opened by right-clicking on a connection and choosing Show.

Tools Contains a single Options dialog, discussed in Advance Usage on page F-5.

Help Contains a single choice ‘About ixTclServer...’. When invoked, a dialog is presented with the version number of ixTclServer.


Tcl Server Usage

The options available in this dialog are:

Advance Usage Additional means of connecting to Tcl Server are provided through the Tcl Server menu. The options for this menu choice are:

Table F-1. IxTclServer Options

Category Option Usage

Output Options

Output Tcl commands in treeview

The last Tcl command executed for a Tcl Server connection is shown in the tree view. For example, in Figure F-4 on page F-3 the phrase: Tcl Interpreter last cmd: session logout.

Output Tcl commands in TclInterpreter window

If a Tcl Interpreter window has been opened with the Tcl Interpreter..Show menu choice, then this option indicates that Tcl commands passed through Tcl Server should be displayed in this window.

Return Tcl command standard output

See Advance Usage on page F-5 for a description of this option.

Logging Options

Log Tcl commands If selected, then a log file is created in the Ixia installation directory (usually C:\Program Files\Ixia). Each connection creates a separate log file whose name includes the year, month, day and seconds since midnight.

Log Tcl command return values

If selected, return values from the Tcl commands are included in the log.

Table F-2. Tcl Server Menu Options

Option Usage

Add Socket Listener... Tcl Server’s socket interface can ‘listen’ to ports other than the default port 4555. This option adds another listener at another port.

Add Serial Listener... Tcl Server can also listen on one of the host’s communications ports. The options associated with this type of connection are shown in Figure F-6 on page F-6. The port selected should be one of the available ports: COM1, COM2, etc. that is not in use by another application.

Add Telnet Listener... Tcl Server can also listen on a port using the Telnet protocol. A dialog allows the port to be selected.

Delete This option deletes the currently selected connection in the main window and all associated Tcl Interpreters shown a child nodes


Tcl Server UsageF

Figure F-6. Serial Port Characteristics

The serial connection and telnet connections are different from the socket listener connection in that they ‘speak’ Tcl. That is, an external program of any type may make a serial or telnet connection to Tcl Server and send it Ixia Tcl commands which will be executed on the Ixia chassis. The results of the commands’ execu-tion are sent back to the external program. If the Return Tcl command standard output option was checked in the Tools..Options dialog, then any output that the command produced would also be sent to the external program.


GThis appendix covers the available statistics for the different card types:

• Statistics for 10/100 Cards and Ethernet/USB Cards in Ethernet Mode. These cards include:

• 10/100

• 10/100 MII

• 10/100 Reduced MII

• 100 Base FX MultiMode

• 100 Base FX SingleMode

• Ethernet/USB operating in Ethernet mode

• Copper 10/100/1000 running at 10/100 Mbps

• Statistics for 10/100 TXS Modules. These cards include:

• 10/100 TXS8

• Statistics for Ethernet/USB cards in USB Mode. These cards include:

• Ethernet/USB

• Statistics for Gigabit Modules. These cards include:

• 1000 Base SX MultiMode

• 1000 Base LX MultiMode

• 1000 Base SX SingleMode

• GBIC

• Statistics for OC12c/OC3c Modules. These cards include:

• OC12c/OC3c

• Statistics for OC48c Modules with Bert. These cards include:

• OC48c POS

• OC48 POS VAR

Appendix G: Available Statistics

Ixia Tcl Development Guide G-1

Table OrganizationG

• OC48c BERT

• OC48c BERT Rx

• OC48c POS BERT

• Statistics for OC192c Modules. These cards include:

• OC192c with optional BERT and 10 Gigabit Ethernet

• Statistics for 10GE Modules. These cards include:

• 10 Gigabit Ethernet

Table OrganizationEach of the following tables details the statistics available for that set of cards. Available statistics are controlled by three sets of controls:

IxExplorer Statistics Modes

From the Explorer tree, select a port and select Filter, Statistics, Receive Mode from the right-hand panel. Select the tab at the top labelled Statistics. This is shown below for a Gigabit module with the statistics modes highlighted in a solid box. The choices here are mutually exclusive. In most cases, when one is selected new statistics are available at the expense of others.

Figure G-7. Statistics Mode Selection

Extra Statistics Checkboxes

Additional statistics are selected through a set of checkboxes located on the same Statistics tab, as highlighted in a dashed line. These statistics are always in addi-tion to those in the Statistics Mode box.

Statistics Mode Extra Statistics Checkboxes

G-2 Ixia Tcl Development Guide

Table Organization

Receive Mode

From the Explorer tree, select a port and select Filter, Statistics, Receive Mode from the right-hand panel. Select the tab at the top labelled Receive Mode. This is shown below for a Gigabit module. Not all of the receive modes necessarily result in additional statistics. For example, in the figure below First Time Stamp and ISL Encapsulation do not affect statistics. Otherwise, the checkboxes gener-ally result in additional statistics.

Figure G-8. Receive Mode Selection

Key To Tables

lists the headings that appear in the tables in this appendix and their correspon-dence to IxExplorer dialogs and selections.Table G-3.Key for Statistics Table

Heading Item IxExplorer Dialog IxExplorer Label

2

UDS 5&6 Statistics User Defined Statistics 5 and 6

QoS Statistics Quality of Service

Normal Statistics Normal

Checksum Errors Statistics IP / TCP / UDP Checksum Verification

Data Integrity Statistics Data Integrity

Extra Statistics Checkboxes

Protocol Server Statistics Protocol Server Stats


Table OrganizationG

TCL Development Statistics Mode

The statistics mode is controlled by the use of the stat mode command. Figure G-7 on page G-2 lists the available choices and their correspondence to IxEx-plorer choices and the labels used in the tables in this appendix.

Extra Statistics

The extra statistics indicated in the tables are always available via the stat com-mand.

ARP STATS Statistics ARP Stats

ICMP STATS Statistics ICMP Stats

BGP STATS Statistics BGP Stats

USB Ext Statistics USB Extended Stats

POS Ext Statistics POS Extended Stats

Temp Sensors Statistics Temperature Sensor Stats

Receive Mode

Rx Capture Receive Mode Capture

Rx Seq Checking Receive Mode Sequence Checking

Rx Data Integrity Receive Mode Data Integrity

Table G-3.Key for Statistics Table

Heading Item IxExplorer Dialog IxExplorer Label

Table G-4.Tcl stat mode Options

Option IxExplorer Choice

statNormal (0) (default) Normal

statQos (1) Quality of Service

statStreamTrigger (2) User Defined Statistics 5 and 6

statModeChecksumErrors (3) IP / TCP / UDP Checksum Verification

statModeDataIntegrity (4) Data Integrity


Table Organization

Receive Mode

The receive mode is controlled through the use of the port receiveMode option. The choices available are or’d together. list the bits available to control the receive mode.

C++ Development Statistics Mode

The statistics mode is controlled by the use of the stat.mode member. Table G-7 on page G-2 lists the available choices and their correspondence to IxExplorer choices and the labels used in the tables in this appendix.

Extra Statistics

The extra statistics indicated in the tables are always available via the stat class.

Table G-5.Tcl port receive Options

Option IxExplorer Choice

portCapture (1) Capture

portPacketGroup (2) Packet Groups

portRxTcpSessions (4) Does not affect statistics.

portRxTcpRoundTrip (8) Does not affect statistics.

portRxDataIntegrity (16) Data Integrity

portRxFirstTimeStamp (32) Does not affect statistics.

portRxSequenceChecking (64) Sequence Checking

Table G-6.C++ stat Members

Member Value IxExplorer Choice

statNormal (0) (default) Normal

statQos (1) Quality of Service

statStreamTrigger (2) User Defined Statistics 5 and 6

statModeChecksumErrors (3) IP / TCP / UDP Checksum Verification

statModeDataIntegrity (4) Data Integrity


Description of StatisticsG

Receive Mode

The receive mode is controlled through the use of the port.receiveMode mem-ber. The choices available are or’d together. list the bits available to control the receive mode.

Description of StatisticsTable G-8 on page G-7 lists all of the available statistics, along with an explana-tion of those statistics.The following three columns are used:

• Counter – the name of the statistics as it appears in IxExplorer. These are organized by general category, as used in the remaining tables in this appen-dix.

• Interpretation – the description of the statistics.

• Internal Baseame – the internal basename used to describe the statistics in the TCL and C++ API. The base name is used to form other names:

• TCL stat command options – the basename is the name of the option.

• TCL stat command get sub-command counterType argument – the counterType name needed to fetch a particular statistic is formed by prepending the letters stat to the basename, while capitalizing the first let-ter of the statistic. For example, for basename alignmentErrors, the coun-terType name is statAlignmentErrors.

• C++ stat class members – the basename is the name of the member.

• C++ stat command get method counterType argument – the counterType name needed to fetch a particular statistic is formed by prepending the letters stat to the basename, while capitalizing the first let-ter of the statistic. For example, for basename alignmentErrors, the coun-terType name is statAlignmentErrors.

.

Table G-7.Tcl port receive Options

Member Value IxExplorer Choice

portCapture (1) Capture

portPacketGroup (2) Packet Gropus

portRxTcpSessions (4) Does not affect statistics.

portRxTcpRoundTrip (8) Does not affect statistics.

portRxDataIntegrity (16) Data Integrity

portRxFirstTimeStamp (32) Does not affect statistics.

portRxSequenceChecking (64) Sequence Checking


Ixia Tcl Developm

ent Guide

G-7

Description of Statistics

T

C Internal Basename

U

U er- userDefinedStat1userDefinedStat2

C as captureTrigger

C s captureFilter

U er-OC192

streamTrigger1streamTrigger2

S

L ort has See

link

L lineSpeed

D 7 in duplexMode

T transmitState

C captureState

P pauseState

C

F is framesSent

able G-8.Statistics Counters

ounter Interpretation

ser Configurable

ser Defined Stats 1 and 2 & Rate Counters that increment each time the statistics conditions are met. The usdefined statistics conditions are set up in the Capture Filter window.

apture Trigger (UDS3) & Rate A counter that increments each time the capture trigger conditions are met,defined in the Capture Filter window.

apture Filter (UDS4) & Rate A counter that increments each time the capture filter conditions are met, adefined in the Capture Filter window.

ser Defined Stats 5 and 6 & Rate Counters that increment each time the statistics conditions are met. The usdefined statistics conditions are set up in the Capture Filter window. (N/A to modules.)

tates

ink State “Up” when a link is established with another device, “Loopback” when the ploopback enabled, “Down” when there is no connection to another device. (note 2 in Notes)

ine Speed “10”, “100”, or “1000” (denoting Mbps) and OC-12, OC-3 or OC-48 for POSmodules. (See note 6 in Notes)

uplex Mode “Half” or “Full”. Half duplex only applies to 10/100 Load Modules. (See noteNotes)

ransmit State Not shown in IxExplorer. The current transmit state of the port. See the statcommand in the Tcl Development Guide and C++ Development Guide.

apture State Not shown in IxExplorer. The current capture state of the port. See the stat command in the Tcl Development Guide and C++ Development Guide.

ause State Not shown in IxExplorer. The current pause state of the port. See the stat command in the Tcl Development Guide and C++ Development Guide.

ommon

rames Sent & Rate A counter that increments only when a frame is successfully transmitted - thcounter does not count collision attempts.


G-8

Ixia Tcl Developm

ent Guide

G

xclusive of it counter

ter than ter.

framesReceived

bytesSent

bytesReceived

transmitDuration

etting is qualityOfService0qualityOfService1...

framerFCSErrors

framerAbort

framerMinLength

framerMaxLength

framerFramesTx

framerFramesRx

ipPackets

udpPackets

tcpPackets

Internal Basename

Valid Frames Received & Rate The valid frame size is from 64 bytes to 1518 bytes inclusive of FCS, epreamble and SFD and must be an integer number of octets. This 32 bonly counts frames with good FCS. VLAN tagged frames that are grea1518 but less than 1522 bytes in size will also be counted by this coun

Bytes Sent & Rate A counter that counts the total number of bytes transmitted.

Bytes Received & Rate A counter that counts the total number of bytes received.

Transmit Duration

Transmit Duration Reserved for future use

Quality of Service

Quality of Service 0 - 7 & Rate Counters which increment each time a frame with that particular QoS sreceived. (N/A to OC192-3)

Framer Stats

Framer CRC Errors CRC errors detected by the POS framer.

Framer Abort POS frames aborted by the Framer.

Framer Min Length & Rate POS frames received with less than the minimum length.

Framer Max Length & Rate POS frames received with more than the maximum length.

Extended Framer Stats

Framer Frames Sent Reserved for future use.

Framer Frames Received Reserved for future use.

Checksum Stats

IP Packets Received The number of IP packets received.

UDP Packets Received The number of UDP packets received.

TCP Packets Received The number of TCP packets received.

Table G-8.Statistics Counters

Counter Interpretation

Ixia Tcl Developm

ent Guide

G-9


I ipChecksumErrors

U udpChecksumErrors

T tcpChecksumErrors

D

D dataIntegrityFrames

D dataIntegrityErrors

S

S sequenceFrames

S sequenceErrors

P

G

P protocolServerTx

P protocolServerRx

T txArpReply

T txArpRequest

T txPingReply

T txPingRequest

R rxArpReply

R rxArpRequest

R rxPingReply

R rxPingRequest

T

C Internal Basename

P Checksum Errors The number of IP checksum errors detected..

DP Checksum Errors The number of UDP checksum errors detected.

CP Checksum Errors The number of TCP checksum errors detected.

ata Integrity

ata Integrity Frames The number of data integrity frames received.

ata Integrity Errors The number of data integrity errors detected.

equence Checking

equence Frames The number of sequence checking frames received.

equence Errors The number of sequence checking errors detected.

rotocol Server Stats

eneral

rotocol Server Transmit Packets transmitted by the protocol handler.

rotocol Server Receive Packets received by the protocol handler.

ransmit Arp Reply Number of ARP replies generated.

ransmit Arp Request Number of ARP requests generated.

ransmit Ping Reply Number of Ping replies generated. (N/A to OC192-3)

ransmit Ping Request Number of Ping requests received. (N/A to OC192-3)

eceive Arp Reply Number of ARP replies received.

eceive Arp Request Number of ARP requests received.

eceive Ping Reply Number of Ping replies received. (N/A to OC192-3)

eceive Ping Request Number of Ping requests generated. (N/A to OC192-3)




G-10

Ixia Tcl Developm

ent Guide

G

bgpTotalSessions

. bgpTotalSessionsEstablished

isisSessionsConfiguredL1

isisSessionsConfiguredL2

isisSessionsUpL1

isisSessionsUpL2

ospfTotalSessions

ospfFullNeighbors

rsvpIngressLSPsConfigured

rsvpIngressLSPsUp

rsvpEgressLSPsUp

with a bad fragments

with a good undersize

size with a oversize

fcsErrors

Internal Basename

BGP

BGP Sessions Configured The number of BGP4 sessions that were configured.

BGP Sessions Established The number of configured BGP4 sessions that established adjacencies

ISIS

ISIS L1 Sessions Configured The total number of level 1 configured sessions.

ISIS L2 Sessions Configured The total number of level 2 configured sessions.

ISIS L1 Sessions Up The total number of level 1 configured sessions that are fully up.

ISIS L2 Sessions Up The total number of level 2 configured sessions that are fully up.

OSPF

OSPF Total Sessions The number of OSPF sessions that were configured.

OSPF Neighbors in Full State The number of OSPF neighbors that are fully up.

RSVP

RSVP Ingress LSPs Configured The number of ingress LSPs configured.

RSVP Ingress LSPs Up The number of ingress LSPs configured and running

RSVP Egress LSPs Up The number of egress LSPs configured and running

Ethernet

Fragments & Rate A counter that counts the number of frames less than 64 bytes in size FCS.

Undersize & Rate A counter that counts the number of frames less than 64 bytes in size FCS.

Oversize & Rate A counter that counts the number of frames greater than 1518 bytes ingood FCS.

CRC Errors & Rate A counter that counts all valid size frames that have CRC errors.



Ixia Tcl Developm

ent Guide

G-11


V vlanTaggedFramesReceived

L symbol symbolErrors

F only rties

flowControlFrames

1

A bits en the ent

alignmentErrors

D bits the bit

dribbleErrors

C ) of the collisions

L ble lateCollisions

C d due collisionFrames

ut had excessiveCollisionFrames

G

O with a oversizeAndCrcErrors

L rrors. symbolErrorFrames

T

C Internal Basename

lan Tagged Frames & Rate A counter that counts the number of VLAN tagged frames.

ine Errors & Rate A counter that counts the number of 4B/5B (100Mbps) or 8B/10B (Gigabit) errors.

low Control Frames & Rate A counter that counts the number of PAUSE frames received. This counter increments when Flow Control is enabled for that port (using the port propedialog).

0/100

lignment Errors & Rate A counter that counts all valid size frames that are not an even multiple of 8and have an invalid FCS. The frame is truncated to the nearest octet and thFCS is validated. If the FCS is bad, then this frame is counted as an alignmerror.

ribble Errors & Rate A counter that counts all valid size frames that are not an even multiple of 8and have a valid FCS. The frame is truncated to the nearest octet and thenFCS is validated. If the FCS is good, then this frame is counted as a dribbleerror.

ollisions & Rate A counter that counts all occurrences (only one count per frame or fragmentCollision Detect signal from the physical layer controller.

ate Collisions & Rate A counter that counts all collisions that occur after the 512th bit time (preamincluded) or after the 56th byte.

ollision Frames & Rate A counter that counts the number of frames received that were retransmitteto one or more collisions.

Excessive Collision Frames & Rate A counter that counts the number of frames that were attempted to be sent b16 or more consecutive collisions.

igabit

versize and CRC Errors & Rate A counter that counts the number of frames greater than 1518 bytes in sizebad FCS.

ine Error Frames & Rate A counter that counts the number of frames received that contain symbol e




G-12

Ixia Tcl Developm

ent Guide

G

etected to synchErrorFrames

sectionLossOfSignal

sectionLossOfFrame

sectionBip

ote 3 in lineAis

es) lineRdi

lineRei

lineBip

note 3 in pathAis

Notes) pathRdi

pathRei

pathBip

es) pathLossOfPointer

el byte. te 5 in

pathPlm

second) at sectionBipErroredSecs

r BIP errors sectionBipSeverlyErroredSecs

Internal Basename

Byte Alignment Error & Rate A counter that counts the number of times that a comma character is dbe out of alignment.

POS

Section LOS “OK” or “ALARM” during loss of signal. (See note 3 in Notes)

Section LOF “OK” or “ALARM” during loss of frame. (See note 3 in Notes)

Section BIP(B1) & Rate The number of section bit interleaved parity errors.

Line AIS “OK” or “ALARM” during a line alarm indication signal condition. (See nNotes)

Line RDI “OK” or “ALARM” during a remote defect indication. (See note 3 in Not

Line REI(FEBE) & Rate A count of the number of remote error indicate conditions.

Line BIP(B2) & Rate The number of line bit interleaved parity errors.

Path AIS “OK” or “ALARM” during a path alarm indication signal condition. (See Notes)

Path RDI “OK” or “ALARM” during a path remote defect indication. (See note 3 in

Path REI(FEBE) & Rate A count of the number of path remote error indicate conditions

Path BIP(B3) & Rate The number of path bit interleaved parity errors.

Path LOP “OK” or “ALARM” during a loss of pointer condition. (See note 3 in Not

Path PLM(C2) Either “OK” or “ALARM” along with the current received path signal lab“ALARM” will occur when a path signal label mismatch occurs. (See noNotes)

Section BIP Errored Seconds A count of the number of seconds during which (at any point during theleast one section layer BIP was detected.

Section BIP Severely Errored Seconds A count of the number of seconds during which K or more Section layewere detected, where K = 2,392 for OC-48 (per ANSI T1.231-1997).



Ixia Tcl Developm

ent Guide

G-13


S ond) at sectionLossOfSignalSecs

L st one lineBipErroredSecs

L by the lineReiErroredSecs

L st one lineAisAlarmSecs

L e far lineRdiUnavailableSec

P st one pathBipErroredSecs

P st one pathReiErroredSecs

P defect pathAisAlarmSec

P ble. pathAisUnavailableSecs

P ble at pathRdiUnavailableSec

I Notes) inputSignalStrength

P posK1byte

P posK2byte

B

S face bertStatus

T

C Internal Basename

ection LOS Seconds A count of the number of seconds during which (at any point during the secleast one section layer LOS defect was present.

ine BIP Errored Seconds A count of the seconds during which (at any point during the second) at leaLine layer BIP was detected.

ine REI Errored Seconds A count of the seconds during which at least one line BIP error was reportedfar end.

ine AIS Alarmed Seconds A count of the seconds during which (at any point during the second) at leaLine layer AIS defect was present.

ine RDI Unavailable Seconds A count of the seconds during which the line is considered unavailable at thend.

ath BIP Errored Seconds A count of the seconds during which (at any point during the second) at leaPath BIP error was detected.

ath REI Errored Seconds A count of the seconds during which (at any point during the second) at leaSTS Path error was reported by the far end.

ath AIS Alarmed Seconds A count of the seconds during which (at any point during the second) an AISwas present)

ath AIS Unavailable Seconds A count of the seconds during which the STS path was considered unavaila

ath RDI Unavailable Seconds A count of the seconds during which the STS path was considered unavailathe far end.

nput Signal Strength (dB) (OC-192) This stat monitors the receive optical input power. (See note 8 in

OS K1 Byte Monitors the k1 status byte in Sonet Headers.

OS K2 Byte Monitors the k1 status byte in Sonet Headers.

ERT

tatus For BERT - The status of the connection. “Locked” when the receiving interlocks onto the data pattern. (See note 1 in Notes)




G-14

Ixia Tcl Developm

ent Guide

G

bertBitsSent

bertBitsReceived

bertBitErrorsSent

bertBitErrorsReceived

he total bertBitErrorRatio

nd. bertErroredBlocks

ock or a bertErroredSeconds

ds. bertErroredSecondRatio

blocks or a bertSeverelyErroredSeconds

e total bertSeverelyErroredSecondsRatio

s. bertErrorFreeSeconds

lable bertAvailableSeconds

available bertUnavailableSeconds

ing to the min. of 10 ble. A min. lable. (See

bertBlockErrorState

of a bertBackgroundBlockErrors

Internal Basename

Bits Sent For BERT - the total number of bits sent.

Bits Received For BERT - the total number of bits received.

Bit Errors Sent For BERT - the total number of bit errors sent.

Bit Errors Received For BERT - the total number of bit errors received.

Bit Error Ratio For BERT - (BER) the ratio of the number of errored bits compared to tnumber of bits transmitted.

Errored Blocks For BERT- (EB) Number of blocks containing at least one errored seco

Errored Seconds For BERT - (ES) Number of seconds containing at least one errored bldefect.

Errored Second Ratio For BERT - (ESR) the ratio of Errored Seconds (ES) to the total secon

Severely Errored Seconds For BERT - (SES) Number of seconds with 30% or more of the erroreddefect.

Severely Errored Second Ratio For BERT - (SESR) the ratio of Severely Errored Seconds (SESs) to thseconds in available time.

Error Free Seconds For BERT - (EFS) Number of seconds with no errored blocks or defect

Available Seconds For BERT - (AS) Number of seconds which have occurred during AvaiPeriods.

Unavailable Seconds For BERT - (UAS) Number of seconds which have occurred during UnPeriods.

Block Error State For BERT - Available Period or Unavailable Period, determined accordrunning count and calculation of seconds in various error conditions. Anon-SESs must pass for the state to change from Unavailable to Availaof 10 SESs must pass for the state to change from Available to Unavainote 4 in Notes)

Background Block Errors For BERT - (BBE) The number of errored blocks not occurring as part Severely Errored Second.



Ixia Tcl Developm

ent Guide

G-15


B l bertBackgroundBlockErrorRatio

E bertElapsedTestTime

N bertNumberMismatchedZeros

M bertismatchedZerosRatio

N bertNumberMismatchedOnes

bertMismatchedOnesRatio

S lable

L onds. bertLastServiceDisruptionTime

M bertMinServiceDisruptionTime

M bertMaxServiceDisruptionTime

C(

bertServiceDisruptionCumulative

O

T

D dMATemperature

C captureTemperature

L latencyTemperature

B . backgroundTemperature

O overlayTemperature

T

C Internal Basename

ackground Block Error Ratio For BERT - (BBER) the ratio of Background Block Errors (BBEs) to the totanumber of blocks in available time.

lapsed Test Time For BERT - the elapsed test time, expressed in seconds.

umber Mismatched Zeros The number of expected zeroes received as ones.

ismatched Zeros Ratio The ratio of the number of expected zeroes received as ones to all bits.

umber Mismatched Ones The number of expected ones received as zeroes.

Mismatched Ones Ratio The ratio of the number of expected ones received as zeroes to all bits.

ervice Disruption A service disruption is the period of time during which the service is unavaiwhile switching rings. The SONET spec calls for this to be less than 50 ms.

ast Service Disruption Time (ms) The length of the last service disruption that occurred, expressed in millisec

in Service Disruption Time (ms) The shortest service disruption that occurred, expressed in milliseconds.

ax Service Disruption Time (ms) The longest service disruption that occurred, expressed in milliseconds.

umulative Service Disruption Time ms)

The total service disruption time encountered, expressed in milliseconds.

C192

emperature

MA Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the DMA chip.

apture Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the Capture chip.

atency Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the Latency chip.

ackground Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the Background chip

verlay Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the Overlay chip.




G-16

Ixia Tcl Developm

ent Guide

G

hip. frontEndTemperature

hip. scheduleTemperature

ture plmDevice1InternalTemperature



sors on the fobPort1FpgaTemperaturefobPort2FpgaTemperature

sors on the fobBoardTemperature

sors on the fobDevice1InternalTemperature

usbTxNoError

usbRxNoError

RC error. usbRxCRCError

it stuffing usbRxBitStuffing

eceived did usbRxToggleMismatch

usbTxStall

usbRxStall

Internal Basename

Front End Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the Front End C

Scheduler Chip Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature of the Scheduler C

Plm Internal Chip Temperature 1 (C) (OC-192 - Temperature Sensors Stats) Internal temperature of temperameasuring device #1.

Plm Internal Chip Temperature 2 (C) (OC-192 - Temperature Sensors Stats) Internal temperature of temperameasuring device #2.

Plm Internal Chip Temperature 3(C) (OC-192 - Temperature Sensors Stats) Internal temperature of temperameasuring device #3.

Fom Port Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature for one of the senFiber optic module (Fom).

Fom Board Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature for one of the senFiber optic module (Fom).

Fom Internal Temperature (C) (OC-192 - Temperature Sensors Stats) Temperature for one of the senFiber optic module (Fom).

USB

Transmit NO Error (For USB Extended Stats) Data packets sent with no errors.

Receive NO Error (For USB Extended Stats) Data packets received with no errors.

Receive CRC Error (For USB Extended Stats) The last data packet received contained a C

Receive Bit Stuffing (For USB Extended Stats) The last data packet received contained a bviolation.

Receive Data Toggle Mismatch (For USB Extended Stats) The data toggle PID for the last data packet rnot match the expected value.

Transmit Stall (For USB Extended Stats) Transmitted a Stall PID.

Receive Stall (For USB Extended Stats) Received a Stall PID.



Ixia Tcl Developm

ent Guide

G-17


T to the usbTxDeviceNotResponding

R nt by usbRxDeviceNotResponding

T usbTxPIDCheckFail

R data usbRxPIDCheckFail

T e. usbTxUnexpectedPID

R usbRxUnexpectedPID

R of: usbRxDataOverrun

R e, so usbRxdataUnderrun

R written usbRxbufferOverrun

T ystem usbTxBufferUnderrun

T aced in usbTxNotAccessed

R aced in usbRxNotAccessed

1

P

P pauseAcknowledge

T

C Internal Basename

ransmit Device Not Responding (For USB Extended Stats) The transmit device did not provide a handshakereceive device.

eceive Device Not Responding (For USB Extended Stats) The receive device did not respond to a token sethe transmit device.

ransmit PID Check Failure (For USB Extended Stats) Check bits in the PID from the endpoint failed onhandshake.

eceive PID Check Failure (For USB Extended Stats) Check bits in the PID from the endpoint failed onPID.

ransmit Unexpected PID (For USB Extended Stats) Transmitted an invalid PID or undefined PID valu

eceive Unexpected PID (For USB Extended Stats) Received an invalid PID or undefined PID value.

eceive Data Overrun (For USB Extended Stats) The amount of data returned exceeded the size • maximum data packet allowed, or• remaining amount of memory in the buffer

eceive Data Underrun (For USB Extended Stats) The endpoint sent less than maximum packet sizthe specified buffer is not filled.

eceive Buffer Overrun (For USB Extended Stats) Receiving port receives data faster than it can beto system memory.

ransmit Buffer Underrun (For USB Extended Stats) During transmission, cannot retrieve data from smemory and send out fast enough to keep up with the USB data rate.

ransmit Not Accessed (For USB Extended Stats) This code is set by software before the RUT is pla queue for processing.

eceive Not Accessed (For USB Extended Stats) This code is set by software before the RUT is pla queue for processing.

0 Gig

ause Frame

ause Acknowledge The number of clocks for which transmit has been paused.




G-18

Ixia Tcl Developm

ent Guide

G

pauseEndFrames

quanta not pauseOverwrite

10GigLanTxFpgaTemperature

10GigLanRxFpgaTemperature

Internal Basename

Pause End Frames The number of pause frames received with a quanta of 0.

Pause Overwrite The number of pause frames received while transmit was paused with aequal to 0

Temperature

Lan Transmit FPGA Temperature For the 10Gig LAN board, the temperature at the transmit FPGA.

Lan Receive FPGA Temperature For the 10Gig LAN board, the temperature at the receive FPGA.



Ixia Tcl Developm

ent Guide

G-19


N
otesTable G-9.Notes for Statistics Counters
Note Choices displayed for Statistic

1 Locked - All Ones

Locked - Inverted Alternating One/Zero

Locked - Inverted User Defined Pattern

Locked - Inverted 2^31 Linear Feedback Shift Reg





Locked - All Zero

Locked - Alternating One/Zero

Locked - User Defined Pattern

Locked - 2^11 Linear Feedback Shift Reg




Not Locked

2 Demo Mode

Link Up

Link Down

Loopback


G-20

Ixia Tcl Developm

ent Guide

G

WriteMii

Restart AutoNegotiate

End RestartAutoNegotiate

AutoNegotiate

WriteMii Failed

No Transceiver

Invalid PHY Address

Read LinkPartner

No LinkPartner

FPGA Download Failed

No GBIC Module

Fifo Reset

Fifo Reset Compete

PPP Off

PPP Up

PPP Down

PPP Init

PPP WaitForOpen

PPP AutoNegotiate

PPP Close

PPP Connect

Table G-9.Notes for Statistics Counters


Ixia Tcl Developm

ent Guide

G-21


Loss of Frame

Loss of Signal

StateMachine Failure

PPP RestartNegotiation

PPP RestartNegotiation Init

PPP RestartNegotiation WaitForOpen

PPP RestartNegotiation WaitForClose

PPP RestartNegotiation Finish

LP Boot Failed

PPP Disabled - LOF

Ignore Link

Temperature Alarm

PPP Closing

PPP LCP Negotiate

PPP Authenticate

PPP NCP Negotiate

3 OK

Alarm

"-"

Defect

4 Unavailable Period




G-22

Ixia Tcl Developm

ent Guide

G

Available Period

5 OK

OK (%)

Alarm (%)

"-"

6 OC-3c

OC-12c

OC-48c

OC-192c

10GE WAN

10 Mbps

100 Mbps

1000 Mbps

7 Full

Half

8 Loss of Signal

[-] %d.%d



Ixia Tcl Developm

ent Guide

G-23


et Mode
Table G-10.Statistics for 10/100 Cards and Ethernet/USB Cards in EthernNormal Qos StreamTrigger
Cap

ture

Pack

etG

roup

RxT

cpR

ound

Trip

RxF

irstT

imeS

tam

p

Cap

ture

Pack

etG

roup

RxT

cpR

ound

Trip

RxF

irstT

imeS

tam

p

Cap

ture

Pack

etG

roup

RxT

cpR

ound

Trip

RxF

irstT

imeS

tam

p

Type: User ConfigurableUserDefinedStat1 X X X X X X X XUserDefinedStat2 X X X X X X X XCaptureTrigger X X X XCaptureFilter X X X XStreamTrigger1 X X XStreamTrigger2 X X XType: StatesLink X X X X X X X X X X X XLineSpeed X X X X X X X X X X X XDuplexMode X X X X X X X X X X X XTransmitState X X X X X X X X X X X XCaptureState X X X X X X X X X X X XPauseState X X X X X X X X X X X XType: CommonFramesSent X X X X X X X X X X X XFramesReceived X X X X X X X X X X X XBytesSent X X X X X X X X X X X XBytesReceived X X X X X X X XFcsErrors X X X X X X X X X X X XType: Transmit DurationTransmitDuration X X X X X X X X X


G-24

Ixia Tcl Developm

ent Guide

Gernet Mode

RxF

irstT

imeS

tam

p

Type: Quality of ServiceQualityOfService0-7 X X XType: EthernetFragments X X X X X X X X X X X XUndersize X X X X X X X X X X X XOversize X X X X X X X X X X X XVlanTaggedFramesRx X XFlowControlFrames X X X X X X X X X X X XType: 10/100AlignmentErrors X X X X X X X X X X X XDribbleErrors X X X X X X X XCollisions X X X X X X X X X X X XLateCollisions X X X X X X X X X X X XCollisionFrames X X X X X X X X X X X XExcessiveCollisionFrames X X X X X X X X X X X XType: 10/100 + GigabitSymbolErrors XOversizeAndCrcErrors

Table G-10.Statistics for 10/100 Cards and Ethernet/USB Cards in EthNormal Qos StreamTrigger

Cap

ture

Pack

etG

roup

RxT

cpR

ound

Trip

RxF

irstT

imeS

tam

p

Cap

ture

Pack

etG

roup

RxT

cpR

ound

Trip

RxF

irstT

imeS

tam

p

Cap

ture

Pack

etG

roup

RxT

cpR

ound

Trip

Ixia Tcl Developm

ent Guide

G-25


Table G-11.Statistics for 10/100 TXS ModulesNormal StreamTri

ggerModeDataIntegrity

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Type: User ConfigurableUserDefinedStat1 X X X X X XUserDefinedStat2 X X X X X XCaptureTrigger X X X XCaptureFilter X X X XStreamTrigger1 X XStreamTrigger2 X XType: StatesLink X X X X X X X X XLineSpeed X X X X X X X X XDuplexMode X X X X X X X X XTransmitState X X X X X X X X XCaptureState X X X X X X X X XPauseState X X X X X X X X XType: CommonFramesSent X X X X X X X X XFramesReceived X X X X X X X X XBytesSent X X X X X X X X XBytesReceived X X X X X XFcsErrors X X X X X X X X X


G-26

Ixia Tcl Developm

ent Guide

G

Type: Transmit DurationTransmitDuration X XType: EthernetFragments X X X X X X X X XUndersize X X X X X X X X XOversize X X X X X X X X XVlanTaggedFramesRx X XFlowControlFrames X X X X X X X X XType: 10/100AlignmentErrorsDribbleErrors X X X X X XCollisions X X X X X X X X XLateCollisions X X X X X X X X XCollisionFrames X X X X X X X X XExcessiveCollisionFrames X X X X X X X X XType: 10/100 + Gigabit• SymbolErrors• OversizeAndCrcErrors X X X X X X X X X

Table G-11.Statistics for 10/100 TXS ModulesNormal StreamTri

ggerModeDataIntegrity

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Ixia Tcl Developm

ent Guide

G-27


Table G-12.Statistics for Ethernet/USB cards in USB ModeNormal Qos Stream

TriggerAdditional Modes

Cap

ture

Pack

etG

roup

Cap

ture

Pack

etG

roup

Cap

ture

Pack

etG

roup

Usb

Exte

nded

Stat

s

Type: User ConfigurableUserDefinedStat1 X X X XUserDefinedStat2 X X X XCaptureTrigger X XCaptureFilter X XStreamTrigger1 XStreamTrigger2 XType: StatesLink X X X X X XLineSpeed X X X X X XDuplexMode X X X X X XTransmitState X X X X X XCaptureState X X X X X XPauseState X X X X X XType: CommonFramesSent X X X X X XFramesReceived X X X X X XBytesSent X X X X X XBytesReceived X X X XFcsErrors


G-28

Ixia Tcl Developm

ent Guide

G

Type: Transmit DurationTransmitDuration X X X X X XType: Quality of ServiceQualityOfService0-7 XType: USBUsbTxNoError XUsbRxNoError XUsbRxCRCError XUsbRxBitStuffing XUsbRxToggleMismatch XUsbTxStall XUsbRxStall XUsbTxDeviceNotResponding XUsbRxDeviceNotResponding XUsbTxPIDCheckFail XUsbRxPIDCheckFail XUsbTxUnexpectedPID XUsbRxUnexpectedPID XUsbRxDataOverrun XUsbRxdataUnderrun XUsbRxBufferOverrun XUsbTxBufferUnderrun X



Cap

ture

Pack

etG

roup

Cap

ture

Pack

etG

roup

Cap

ture

Pack

etG

roup

Usb

Exte

nded

Stat

s

Ixia Tcl Developm

ent Guide

G-29


UsbTxNotAccessed XUsbRxNotAccessed X



Cap

ture

Pack

etG

roup

Cap

ture

Pack

etG

roup

Cap

ture

Pack

etG

roup

Usb

Exte

nded

Stat

s


G-30

Ixia Tcl Developm

ent Guide

G

ksum ModeDataIntegrity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

X X

XX

X X X X X X XX X X X X X XX X X X X X XX X X X X X XX X X X X X XX X X X X X X

X X X X X X XX X X X X X XX X X X X X XX XX X X X X X X

Table G-13.Statistics for Gigabit ModulesNormal Qos StreamTrigger ModeChec

Errors

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

Type: User ConfigurableUserDefinedStat1 X X X X X X X X X X X X XUserDefinedStat2 X X X X X X X X X XCaptureTrigger X X X X X X X XCaptureFilter X X X X X X X XStreamTrigger1 X X X XStreamTrigger2 X X X XType: StatesLink X X X X X X X X X X X X X X X X X XLineSpeed X X X X X X X X X X X X X X X X X XDuplexMode X X X X X X X X X X X X X X X X X XTransmitState X X X X X X X X X X X X X X X X X XCaptureState X X X X X X X X X X X X X X X X X XPauseState X X X X X X X X X X X X X X X X X XType: CommonFramesSent X X X X X X X X X X X X X X X X X XFramesReceived X X X X X X X X X X X X X X X X X XBytesSent X X X X X X X X X X X X X X X X X XBytesReceived X X X X X X X X X X X X XFcsErrors X X X X X X X X X X X X X X X X X X

Ixia Tcl Developm

ent Guide

G-31


TT X X X X X XTQTI XU XT XI XU XT XTD XD XTS X XS X XTF X X X X X XU X X X X X XO X X X X X X

TModeDataIntegrity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

ype: Transmit DurationransmitDuration X X X X X X X X X X X X X X X X X X Xype: Quality of ServiceualityOfService0-7 X X X Xype: Checksum StatspPackets X X XdpPackets X X XcpPackets X X XpChecksumErrors X X XdpChecksumErrors X X XcpChecksumErrors X X Xype: Data IntegrityataIntegrityFramesataIntegrityErrorsype: Sequence CheckingequenceFrames X X XequenceErrors X X Xype: Ethernetragments X X X X X X X X X X X X X X X X X X Xndersize X X X X X X X X X X X X X X X X X X Xversize X X X X X X X X X X X X X X X X X X X

able G-13.Statistics for Gigabit ModulesNormal Qos StreamTrigger ModeChecksum

Errors

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p


G-32

Ixia Tcl Developm

ent Guide

G

X

X X X X XX

X X X X X X X

ksum ModeDataIntegrity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

VlanTaggedFramesRx X X X XFlowControlFrames X X X X X X X X X X X X X X XType: GigabitSymbolErrorFrames X X X X X X X X X X X XSynchErrorFrames X X X X X X X X X X X X X X XType: 10/100 + GigabitSymbolErrors X X X XOversizeAndCrcErrors X X X X X X X X X X X X X X X X X X

Table G-13.Statistics for Gigabit ModulesNormal Qos StreamTrigger ModeChec

Errors

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxF

irstT

imeS

tam

p

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

Ixia Tcl Developm

ent Guide

G-33


TDataity

Additional Modes

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

PosE

xten

dedS

tats

TUUCCSSTL X XL X XD X XT X XC X XP X XTF X XF X XB X XB

able G-14.Statistics for OC12c/OC3c ModulesNormal Qos StreamTrigger Mode

ChecksumErrors

ModeIntegr

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

ype: User ConfigurableserDefinedStat1 X X X X X X X X X X X XserDefinedStat2 X X X X X X X XaptureTrigger X X XaptureFilter X X XtreamTrigger1 X X X XtreamTrigger2 X X X Xype: Statesink X X X X X X X X X X X X X X X X X XineSpeed X X X X X X X X X X X X X X X X X XuplexMode X X X X X X X X X X X X X X X X X XransmitState X X X X X X X X X X X X X X X X X XaptureState X X X X X X X X X X X X X X X X X XauseState X X X X X X X X X X X X X X X X X Xype: CommonramesSent X X X X X X X X X X X X X X X X X XramesReceived X X X X X X X X X X X X X X X X X XytesSent X X X X X X X X X X X X X X X X X XytesReceived X X X X X X X X X X X X


G-34

Ixia Tcl Developm

ent Guide

G

X X X

X X X

XXX

XX

odeDatategrity

Additional Modes

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

PosE

xten

dedS

tats

FcsErrors X X X X X X X X X X X X X X X X XType: Transmit DurationTransmitDuration X X X X X X X X X X X X X X X X XType: Quality of ServiceQualityOfService0-7 X X X XType: FramerFramerFCSErrorsFramerAbortFramerMinLengthFramerMaxLengthType: Checksum StatsIpPacketsUdpPackets XTcpPackets XIpChecksumErrors XUdpChecksumErrors XTcpChecksumErrors XType: Data IntegrityDataIntegrityFramesDataIntegrityErrorsType: Sequence Checking

Table G-14.Statistics for OC12c/OC3c ModulesNormal Qos StreamTrigger Mode

ChecksumErrors

MIn

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Ixia Tcl Developm

ent Guide

G-35


S XS XTS XS XS XL XL XL XL XP XP XP XP XP XP XSSSLL

TDataity

Additional Modes

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

PosE

xten

dedS

tats

equenceFrames X X X XequenceErrors X X X Xype: POSectionLossOfSignalectionLossOfFrameectionBipineAisineRdiineReiineBipathAisathRdiathReiathBipathLossOfPointerathPlmectionBipErroredSecsectionBipSeverlyErroredSecsectionLossOfSignalSecsineBipErroredSecsineReiErroredSecs

able G-14.Statistics for OC12c/OC3c ModulesNormal Qos StreamTrigger Mode

ChecksumErrors

ModeIntegr

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture


G-36

Ixia Tcl Developm

ent Guide

G

odeDatategrity

Additional Modes

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

PosE

xten

dedS

tats

LineAisAlarmSecsLineRdiUnavailableSecsPathBipErroredSecsPathReiErroredSecsPathAisAlarmSecsPathAisUnavailableSecsPathRdiUnavailableSecsInputSignalStrengthPosK1BytePosK2Byte

Table G-14.Statistics for OC12c/OC3c ModulesNormal Qos StreamTrigger Mode

ChecksumErrors

MIn

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Ixia Tcl Developm

ent Guide

G-37


Trity Additional

Modes

RxM

odeB

ert

PosE

xten

dedS

tats

TUUCCSSTL XL XD XT XC XP XTF XF XB XB

able G-15.Statistics for OC48c Modules with BertNormal Qos StreamTrigger ModeDataInteg

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

ype: User ConfigurableserDefinedStat1 X X X X X X X X X XserDefinedStat2 X X X X X X X X X XaptureTrigger X XaptureFilter X XtreamTrigger1 X X X X XtreamTrigger2 X X X X Xype: Statesink X X X X X X X X X X X X X X X X X X XineSpeed X X X X X X X X X X X X X X X X X X XuplexMode X X X X X X X X X X X X X X X X X X XransmitState X X X X X X X X X X X X X X X X X X XaptureState X X X X X X X X X X X X X X X X X X XauseState X X X X X X X X X X X X X X X X X X Xype: CommonramesSent X X X X X X X X X X X X X X X X X X XramesReceived X X X X X X X X X X X X X X X X X X XytesSent X X X X X X X X X X X X X X X X X X XytesReceived X X X X X X X X X X


G-38

Ixia Tcl Developm

ent Guide

G

X X

X X

XX

XXXXXXXXXX

Integrity Additional Modes

RxS

eque

nceC

heck

ing

RxM

odeB

ert

PosE

xten

dedS

tats

FcsErrors X X X X X X X X X X X X X X X X X XType: Transmit DurationTransmitDuration X X X X X X X X X X X X X X X X X XType: Quality of ServiceQualityOfService0-7 X X X X XType: Data IntegrityDataIntegrityFrames XDataIntegrityErrors XType: Sequence CheckingSequenceFrames X X XSequenceErrors X X XType: POSSectionLossOfSignalSectionLossOfFrameSectionBipLineAisLineRdiLineReiLineBipPathAisPathRdiPathRei

Table G-15.Statistics for OC48c Modules with BertNormal Qos StreamTrigger ModeData

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

Ixia Tcl Developm

ent Guide

G-39


P XP XP XS XS XS XL XL XL XL XP XP XP XP XP XIPP

Trity Additional

Modes

RxM

odeB

ert

PosE

xten

dedS

tats

athBipathLossOfPointerathPlmectionBipErroredSecs X X X X X X X X X X X X X X X X X X XectionBipSeverlyErroredSecs X X X X X X X X X X X X X X X X X X XectionLossOfSignalSecs X X X X X X X X X X X X X X X X X X XineBipErroredSecs X X X X X X X X X X X X X X X X X X XineReiErroredSecs X X X X X X X X X X X X X X X X X X XineAisAlarmSecs X X X X X X X X X X X X X X X X X X XineRdiUnavailableSecs X X X X X X X X X X X X X X X X X X XathBipErroredSecs X X X X X X X X X X X X X X X X X X XathReiErroredSecs X X X X X X X X X X X X X X X X X X XathAisAlarmSecs X X X X X X X X X X X X X X X X X X XathAisUnavailableSecs X X X X X X X X X X X X X X X X X X XathRdiUnavailableSecs X X X X X X X X X X X X X X X X X X X

nputSignalStrengthosK1ByteosK2Byte

able G-15.Statistics for OC48c Modules with BertNormal Qos StreamTrigger ModeDataInteg

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing


G-40

Ixia Tcl Developm

ent Guide

G

Additional Modes

RxM

odeB

ert

PosE

xten

dedS

tats

Tem

pera

ture

Sens

orsS

tats

XXXXXX

XXX

Table G-16.Statistics for OC192c ModulesNormal Qos ModeDataIntegrity

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Type: User ConfigurableUserDefinedStat1 X X X X XUserDefinedStat2 X X X X XCaptureTrigger XCaptureFilter XStreamTrigger1StreamTrigger2Type: StatesLink X X X X X X X X X X X X X XLineSpeed X X X X X X X X X X X X X XDuplexMode X X X X X X X X X X X X X XTransmitState X X X X X X X X X X X X X XCaptureState X X X X X X X X X X X X X XPauseState X X X X X X X X X X X X X XType: CommonFramesSent X X X X X X X X X X X X X XFramesReceived X X X X X X X X X X X X X XBytesSent X X X X X X X X X X X X X XBytesReceived X X X X X

Ixia Tcl Developm

ent Guide

G-41


FTDDTSSTS XS XS XL XL XL XL XP XP XP XP XP X

T Additional Modes

RxM

odeB

ert

PosE

xten

dedS

tats

Tem

pera

ture

Sens

orsS

tats

csErrors X X X X X X X X X X X X X X Xype: Data IntegrityataIntegrityFrames X X XataIntegrityErrors X X Xype: Sequence CheckingequenceFrames X X XequenceErrors X X Xype: POSectionLossOfSignalectionLossOfFrameectionBipineAisineRdiineReiineBipathAisathRdiathReiathBipathLossOfPointer

able G-16.Statistics for OC192c ModulesNormal Qos ModeDataIntegrity

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing


G-42

Ixia Tcl Developm

ent Guide

G

X

X

XXX

Additional Modes

RxM

odeB

ert

PosE

xten

dedS

tats

Tem

pera

ture

Sens

orsS

tats

PathPlmSectionBipErroredSecsSectionBipSeverlyErroredSecsSectionLossOfSignalSecsLineBipErroredSecsLineReiErroredSecsLineAisAlarmSecsLineRdiUnavailableSecsPathBipErroredSecsPathReiErroredSecsPathAisAlarmSecsPathAisUnavailableSecsPathRdiUnavailableSecsInputSignalStrength X X X X X X X X X X X X X XPosK1BytePosK2ByteType: OC192 - TemperatureDMATemperatureCaptureTemperatureLatencyTemperature

Table G-16.Statistics for OC192c ModulesNormal Qos ModeDataIntegrity

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

Ixia Tcl Developm

ent Guide

G-43


B XO XF XS XP XP XP XF XFF XF X

T Additional Modes

RxM

odeB

ert

PosE

xten

dedS

tats

Tem

pera

ture

Sens

orsS

tats

ackgroundTemperatureverlayTemperaturerontEndTemperaturechedulerTemperaturelmDevice1InternalTemperaturelmDevice2InternalTemperaturelmDevice3InternalTemperatureobPort1FpgaTemperatureobPort2FpgaTemperatureobBoardTemperatureobDevice1InternalTemperature

able G-16.Statistics for OC192c ModulesNormal Qos ModeDataIntegrity

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing

RxM

odeB

ert

Cap

ture

Pack

etG

roup

RxD

ataI

nteg

rity

RxS

eque

nceC

heck

ing


G-44

Ixia Tcl Developm

ent Guide

G

Table G-17.Statistics for 10GE ModulesNormal Additional

Modes

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Tem

pera

ture

Sens

orsS

tats

Type: User ConfigurableUserDefinedStat1 X X XUserDefinedStat2 X X XCaptureTrigger XCaptureFilter XStreamTrigger1StreamTrigger2Type: StatesLink X X XLineSpeed X X XDuplexMode X X XTransmitState X X XCaptureState X X XPauseState X X XType: CommonFramesSent X X XFramesReceived X X XBytesSent X X XBytesReceived X X X

Ixia Tcl Developm

ent Guide

G-45


FcsErrors X X XType: Sequence CheckingSequenceFrames XSequenceErrors XType: EthernetFragments X X XUndersize X X XOversize X X XVlanTaggedFramesRxFlowControlFrames X X XType: 10/100 + GigabitSymbolErrorsOversizeAndCrcErrors X X XType: OC192 - TemperatureDMATemperature XCaptureTemperature XLatencyTemperature XBackgroundTemperature XOverlayTemperature XFrontEndTemperature X


Modes

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Tem

pera

ture

Sens

orsS

tats


G-46

Ixia Tcl Developm

ent Guide

G

SchedulerTemperature XPlmDevice1InternalTemperature XPlmDevice2InternalTemperature XPlmDevice3InternalTemperature XFobPort1FpgaTemperatureFobPort2FpgaTemperatureFobBoardTemperatureFobDevice1InternalTemperatureType: 10 Gig - Pause FramePauseAcknowledge X X XPauseEndFrames X X XPauseOverwrite X X X


Modes

Cap

ture

Pack

etG

roup

RxS

eque

nceC

heck

ing

Tem

pera

ture

Sens

orsS

tats

Description of StatisticsG


Index

Index

Numerics10/100 Mii 5-410GE 5-7

AAdvance to Next Stream 3-5Advanced Scheduler 5-5Advanced Stream Scheduling 3-5advertise1000FullDuplex 5-6advertise100FullDuplex 5-6advertise100HalfDuplex 5-6advertise10FullDuplex 5-6advertise10HalflDuplex 5-6advertiseAbilities 5-6API 4-1API Structure and Conventions 4-1Area ID 3-19ARP 3-16, 3-17, 5-29, 5-48, 6-23arp 5-29, A-2arpAddressTableEntry 5-49, A-7arpServer 5-48, A-8Available Seconds G-14

BBackground Block Error Ratio G-15Background Block Errors G-14Background Chip Temperature G-15BERT 5-4, 5-5bert 5-15bertErrorGeneration 5-15, A-16BGP

External 3-20Internal 3-20

BGP4 3-16, 5-53, 6-25bgp4AsPathItem A-19bgp4ExternalNeighborItem 5-54, A-21bgp4ExternalTable 5-54, A-23bgp4InternalNeighborItem 5-54, A-25bgp4InternalTable 5-54, A-27bgp4RouteItem 5-55, A-29bgp4Server 5-53, A-33bgp4StatsQuery A-37Bit Error Rate Testing 5-5, A-12

Bit Error Ratio G-14Bit Errors Received G-14Bit Errors Sent G-14Bits Received G-14Bits Sent G-14Block Error State G-14Border Gateway Protocol 3-19bpg4AsPathItem 5-57broadcastTopology 5-3Bursts 3-4, 3-6byte2IpAddr 6-17, B-2Bytes Received Rate G-8Bytes Sent Rate G-8

CC 1-1, 1-2, 3-48calculateFrameRate 6-16, B-3calculateGap 6-16, B-4Calculation Utilities 6-16Capture 3-8, 5-5capture 5-38, A-45Capture Chip Temperature G-15Capture Data 6-20Capture Filter 3-9Capture State G-7Capture Trigger 3-9captureBuffer 5-39, A-49card 5-4, A-53Card Modules 3-3Cards 5-2CDMA Server 5-3cget 4-1Chassis 3-2, 5-2, 6-6chassis 5-4, A-57Chassis Chaining 3-1

Sync-in 3-1Sync-out 3-1

chassisChain 5-3, A-62CLNP 3-24cluster-list 3-20Collision 3-10collisionBackoff A-64community 3-21Complete SNP 3-25confederation 3-20config 4-1

Ixia Tcl Development Guide Index-1

Index

Console Output 6-27Continuous Burst 3-5Continuous Packet 3-5Counted Burst 3-5CSNP 3-25, 3-26Cumulative Service Disruption Time G-15Cut Through Latency 3-12

DData Capture 5-36, 6-18Data generators 3-7Data Integrity 3-13, 5-5Data Integrity Checking Operation 3-13Data Integrity Errors G-9Data Integrity Frames G-9Data Link Layer 3-7, 5-26Data Patterns 3-7Data Transmission 5-17, 6-12dataIntegrity 5-24, A-65dead interval 3-26decode 4-2dectohex 6-17, B-5Default Gateway 3-17Designated Router 3-26Device Under Test 3-2dhcp 5-35, A-69disableUdfs 6-14, B-6DLL 1-3, 3-50DMA Chip Temperature G-15Dual IS-IS 3-24DUT 3-2

EEBGP 3-20Elapsed Test Time G-15Error Free Seconds G-14Errored Blocks G-14Errored Second Ratio G-14Errored Seconds G-14Expect 1-3External BGP 3-20

Ffastpath B-7filter 5-36, A-76filter config 4-7

filterPallette 5-37, A-83filterPallette config 4-7First Time Stamp 5-5Flows 3-5, 5-17Fom Board Temperature G-16Fom Internal Temperature G-16Fom Port Temperature G-16Forced Collisions 3-11forcedCollisions 5-25, A-87Frame Check Sequence 3-8Frame Data 3-4, 3-7, 5-21

Data generators 3-7Data Patterns 3-7Frame Check Sequence 3-8Frame Identity Record 3-7Frame Size 3-7High speed 32 bit counters 3-7MAC Addresses 3-7Preamble Size 3-7Protocol related data 3-7

Frame Identity Record 3-7Frame Size 3-7Framer Abort G-8Framer CRC Errors G-8Framer Frames Received G-8Framer Frames Sent G-8Framer Max Length & Rate G-8Framer Min Length & Rate G-8frameRelay 5-14, A-90Frames Sent Rate G-7Front End Chip Temperature G-16

GGeneral Purpose Commands 6-9get 4-2GPS 3-42GPS Server 5-3

Hhalf duplex 3-10hdlc 5-14, A-93hello interval 3-26Hello PDU 3-24hextodec 6-17, B-8High-Level API 6-1host2addr 6-17, B-9

Index-2 Ixia Tcl Development Guide

Index

IIBGP 3-20icmp A-98IGMP 3-16, 3-17, 5-50, 6-24igmp 5-33, A-102igmpAddressTable 5-51, A-105igmpAddressTableItem 5-52, A-107igmpServer 5-50, A-109Including Source Code 6-6Initialization 6-3Input Signal Strength G-13Integrated IS-IS 3-24Inter-Burst Gap 3-6Intermediate System 3-24Internal BGP 3-20Inter-Stream Gap 3-6IP 5-30, 5-45ip 5-30, A-112IP Checksum Errors G-9ip config 4-6IP Packets Received G-8IP protocol server support 3-17ipAddressTable 5-45, A-118ipAddressTableItem 5-47, A-120IPX 5-28ipx 5-28, A-122IS 3-16IS-IS 3-24isisInterface 5-69, A-128isisRouter 5-67, A-130isisRouteRange 5-69isisServer 5-66, A-134isl 5-26, A-139ixCheckLinkState 6-12, C-2ixCheckOwnership 6-10, C-4ixCheckPortTransmitDone 6-15, C-7ixCheckPPPState 6-13, C-6ixCheckTransmitDone 6-15, C-9ixClearArpTable 6-23, C-11ixClearOwnership 6-10, C-12ixClearPortArpTable 6-23, C-13ixClearPortStats 6-19, C-14ixClearStats 6-19, C-15ixClearTimeStamp 6-19, C-17ixCollectStats 6-20, C-19

ixConnectToChassis 6-8, C-21ixConnectToTclServer 6-7, C-23IxCoreTM 3-48ixCreatePortListWildCard 6-5, C-24ixCreateSortedPortList 6-6, C-25ixDisableArpResponse 6-23ixDisablePortArpResponse 6-23ixDisconnectFromChassis 6-8, C-29ixDisconnectTclServer 6-7, C-30IxEdgeTM 3-48ixEnableArpResponse 6-23ixEnablePortArpResponse 6-23IxExplorer 1-1, 1-2, 3-48ixGetChassisID 6-8, C-35IxHAL 1-2IXIA 100 5-2IXIA 1600 1-1IXIA 400 1-1Ixia Software 3-48ixInitialize 6-7, C-36ixLogin 6-10, C-46ixLogout 6-10, C-47IxMappingTM 3-48ixPortClearOwnership 6-10, C-48ixPortTakeOwnership 6-10, C-49IxProfileTM 3-48ixProxyConnect 6-7, C-50ixPuts 6-27, C-52ixResetPortSequenceIndex 6-19, C-53ixResetSequenceIndex 6-19, C-54IxSampleTcl.tcl 2-1, 2-4IxServer 1-2, 3-50, 3-51, 3-52ixSetCaptureMode 6-18, C-56ixSetPacketFlowMode 6-13, C-58ixSetPacketGroupMode 6-18, C-60ixSetPacketStreamMode 6-13, C-62ixSetPortCaptureMode 6-18, C-64ixSetPortPacketFlowMode 6-13, C-65ixSetPortPacketGroupMode 6-18, C-66ixSetPortPacketStreamMode 6-13, C-67ixSetPortTcpRoundTripFlowMode 6-14, C-68ixSetTcpRoundTripFlowMode 6-14, C-69ixSource 6-6, C-71ixStartBGP4 6-25, C-72ixStartCapture 6-20, C-74


Index

ixStartCollisions 6-15, C-76ixStartIsis C-78ixStartOSPF 6-25ixStartOspf C-80ixStartPacketGroups 6-20, C-82ixStartPortCapture C-84ixStartPortCollisions 6-15, C-85ixStartPortPacketGroups 6-20, C-87ixStartPortTransmit 6-14, C-89ixStartRip C-90ixStartRsvp C-92ixStartStaggeredTransmit 6-15, C-94ixStartTransmit 6-14, C-96ixStopBGP4 6-25, C-98ixStopCapture 6-20, C-100ixStopCollisions 6-15, C-102ixStopISIS 6-25ixStopIsis C-104ixStopOSPF 6-25ixStopOspf C-106ixStopPacketGroups 6-20, C-108ixStopPortCapture 6-20, C-110ixStopPortCollisions 6-15, C-112ixStopPortPacketGroups 6-20, C-114ixStopPortTransmit 6-14, C-116ixStopRIP 6-25ixStopRSVP 6-25ixStopRsvp C-119ixStopTransmit 6-14, C-121ixTakeOwnership 6-10, C-123IxTclHAL 1-2IxTclHal 4-4IxTclHAL.dll 5-2IxTrafficTM 3-48ixTransmitArpRequest 6-24, C-124ixTransmitIgmpJoin 6-24, C-126ixTransmitIgmpLeave 6-24, C-128ixTransmitPortArpRequest 6-24, C-130ixWriteConfigToHardware 6-9, C-133ixWritePortsToHardware 6-9, C-135

LLast Service Disruption Time G-15Latency 3-11, 3-15Latency Chip Temperature G-15

learn B-10Line AIS G-12Line AIS Alarmed Seconds G-13Line BIP Errored Seconds G-13Line BIP(B2) G-12Line RDI G-12Line RDI Unavailable Seconds G-13Line REI Errored Seconds G-13Line REI(FEBE) G-12Link State PDU 3-24Linux 2-1logger 6-28, B-15Logging 6-27logMsg 6-27, B-12logOff 6-27, B-13logOn 6-27, B-14LSP 3-24, 3-26

MMAC Addresses 3-7Many to Many mapping 4-5Many to One mapping 4-4many2manyArray 4-5, 4-8, 6-4many2oneArray 4-5, 4-8, 6-4Many-to-many mapping 6-3Many-to-One mapping 6-3map 4-4, 6-5, B-16Mapping 6-3mapping 4-4Max Service Disruption Time G-15mii 5-7, A-142Min Service Disruption Time G-15Mismatched Ones Ratio G-15Mismatched Zeros Ratio G-15mpls 5-27, A-151mplsLabel 5-27, A-154Multiple Clients 3-53

NNumber Mismatched Ones G-15Number Mismatched Zeros G-15

OOne to Many mapping 4-4One to One mapping 4-4one2manyArray 4-5, 4-8, 6-4


Index

one2oneArray 4-5, 4-8, 6-4One-to-Many mapping 6-3One-to-One mapping 6-3Open Shortest Path First 3-17originator-id 3-20OSPF 3-16, 5-58, 6-25ospfInterface 5-62, A-156ospfRouter 5-59, A-159ospfRouteRange 5-61ospfRouterLSAInterface 5-65ospfRouterLsaInterface A-164ospfServer 5-58, A-166ospfUserLSA 5-64ospfUserLsa A-171ospfUserLSAGroup 5-64ospfUserLsaGroup A-176Overlay Chip Temperature G-15Oversize G-10

Ppackage require 1-3, 4-4Packet flow 5-5Packet Group Operation 3-11Packet Groups 3-8Packet over Sonet 3-15, 5-4, 5-10Packet size 3-9Packet stream 5-5PacketGroup 5-5packetGroup 5-23, A-178packetGroupStats A-183Packets 3-4, 3-6Partial SNP 3-25Path AIS G-12Path AIS Alarmed Seconds G-13Path AIS Unavailable Seconds G-13Path BIP Errored Seconds G-13Path BIP(B3) G-12Path LOP G-12Path PLM(C2) G-12Path RDI G-12Path RDI Unavailable Seconds G-13Path REI G-12Path REI Errored Seconds G-13Pause Acknowledge G-17Pause End Frames G-18

Pause Overwrite G-18Pause State G-7Pause Transmit 3-8PC Clock 5-3PDU 3-24Ping 3-16Plm Internal Chip Temperature G-16Plm Internal Chip Temperature 1 G-16Plm Internal Chip Temperature 2 G-16port 5-4, A-185port config 4-5Port Hardware 3-4Port Lists 6-3Port Ownership 6-10Port Transmit Capabilities 3-4portGroup A-201portGroups 5-15Ports 5-2POS 5-4POS K1 Byte G-13POS K2 Byte G-13ppp 5-12, A-205pppStatus 5-12, A-210Preamble Size 3-7protocol 5-25, A-213Protocol Data Unit 3-24Protocol Server 5-45, 6-22Protocol Server Receive G-9Protocol Server Transmit G-9Protocols 5-25protocolServer 5-45, A-216PSNP 3-25, 3-26

Qqos A-219Quality of Service G-8Quality of Service Statistics 3-14

RReceive Arp Reply G-9Receive Arp Request G-9Receive Bit Stuffing G-16Receive Buffer Overrun G-17Receive CRC Error G-16Receive Data Overrun G-17Receive Data Toggle Mismatch G-16


Index

Receive Data Underrun G-17Receive Device Not Responding G-17Receive Mode 3-8Receive NO Error G-16Receive Not Accessed G-17Receive PID Check Failure G-17Receive Ping Reply G-9Receive Ping Request G-9Receive Stall G-16Receive Unexpected PID G-17Red Hat Linux 2-1Reset Sequence Index 3-13Return to First for Count 3-6Return to ID 3-6RFC 1112 3-17RFC 2236 3-17RFC 2328 3-17RFC 2828 3-19RIP 3-16, 3-23rip A-222ripInterfaceRouter 5-81, A-227ripRoute 5-34, A-225ripRouteRange 5-83ripServer 5-80, A-231route coloring 3-21route reflection 3-20Router ID 3-19RSVP 3-16, 5-71, 6-25rsvpDestinationRange 5-74, A-235rsvpEroItem 5-78rsvpNeighborPair 5-72, A-241rsvpServer A-248

SScheduler Chip Temperature G-16Scriptgen 3-49ScriptMate 1-2, 3-48Section BIP Errored Seconds G-12Section BIP Severely Errored Seconds G-12Section BIP(B1) G-12Section LOF G-12Section LOS G-12Section LOS Seconds G-13send D-2, D-3, D-4, D-5Sequence Checking 5-5, 5-24

Sequence Checking Operation 3-13Sequence Number PDU 3-25session 5-2, A-252set 4-1setDefault 4-2Setup 6-3Severely Errored Second Ratio G-14Severely Errored Seconds G-14SNP 3-25SNTP Server 5-3Solaris 2-1sonet 5-10, A-254sonetError 5-11, A-258Staggered Start Transmit 3-8Start Capture 3-10Start Collision 3-10Start Latency 3-10Start Transmit 3-8, 6-14startTime 5-3stat 5-41, A-262statGroup 5-42, A-279Statistics 3-14, 5-36, 6-18, 6-20statList A-281Status G-13Step Stream 3-8Stop After This Stream 3-5Stop Capture 3-10Stop Collision 3-10Stop Latency 3-10Stop Transmit 3-8Store and Forward 3-12Store and Forward Preamble 3-12stream 5-17, A-282stream config 4-6Stream Control

Advance to Next Stream 3-5Bursts 3-6Continuous Burst 3-5Continuous Packet 3-5Counted Burst 3-5Inter-Burst Gap 3-6Inter-Stream Gap 3-6Packets 3-6Return to First for Count 3-6Stop After This Stream 3-5

Streams 3-4, 5-17Sun Solaris 2-1


Index

Sync-in 3-1Sync-out 3-1

TTCL 3-48Tcl/Tk 1-3Tcl-DP 1-3Tcl-DP Server 3-52TclHAL 3-50, 3-51, 3-52TclServer 6-6tcp 5-31, A-291TCP Checksum Errors G-9TCP Packets Received G-8TCP Round Trip 5-5TCP Round Trips 5-5tcpRoundTripFlow A-294tcpRoundTripFlows 5-22Theory of Operation 3-1timeServer 5-2, 5-3, A-299Transmit Arp Reply G-9Transmit Arp Request G-9Transmit Buffer Underrun G-17Transmit Device Not Responding G-17Transmit Duration G-8Transmit Mode 3-5Transmit NO Error G-16Transmit Not Accessed G-17Transmit PID Check Failure G-17Transmit Ping Reply G-9Transmit Ping Request G-9Transmit Stall G-16Transmit State G-7Transmit Unexpected PID G-17Type-3 3-3, 3-5, 3-8, 3-11, 3-13

Uudf 5-21, A-303UDF Cascade 5-22udf config 4-7udp 5-32, A-307UDP Checksum Errors G-9UDP Packets Received G-8uery 5-57Unavailable Seconds G-14Universal Serial Bus 5-4USB 5-10

usb A-310user 6-8, B-19User Defined Fields 5-21User Defined Statistics 3-14

VValid Frames Received Rate G-8validateFramesize 6-16, B-20validatePreamblesize 6-16, B-21version 5-2, A-312virtual chassis chain 3-40vlan 5-26, A-314

WWish 1-3write 4-2


Index


t cl development guide

Documents