Ix Automate

Aptixia IxAutomate User Guide
Release 6.90
Part No. 913-0969 Rev D July 2010
Copyright 2010 Ixia. All rights reserved. This publication may not be copied, in whole or in part, without Ixias consent. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.22719. Ixia, the Ixia logo, and all Ixia brand names and product names in this document are either trademarks or registered trademarks of Ixia in the United States and/or other countries. All other trademarks belong to their respective owners. The information herein is furnished for informational use only, is subject to change by Ixia without notice, and should not be construed as a commitment by Ixia. Ixia assumes no responsibility or liability for any errors or inaccuracies contained in this publication.
Corporate Headquarters
Ixia Worldwide Headquarters 26601 W. Agoura Rd. Calabasas, CA 91302 USA +1 877 FOR IXIA (877 367 4942) +1 818 871 1800 (International) (FAX) +1 818 871 1805 sales@ixiacom.com
Web site: www.ixiacom.com General: info@ixiacom.com Investor Relations: ir@ixiacom.com Training: training@ixiacom.com Support: support@ixiacom.com +1 818 595 2599 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ Support: eurosupport@ixiacom.com +44 1628 405797 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ ?location=emea
EMEA
Ixia Europe Limited One Globeside, Fieldhouse Lane Marlow, SL7 1HZ United Kingdom +44 1628 405750 FAX +44 1628 405790 salesemea@ixiacom.com
Asia Pacific
Ixia Pte Ltd 210 Middle Road #08-01 IOI Plaza Singapore 188994
Support: Support-AsiaPac@ixiacom.com +65 6332125 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ Support: Support-Japan@ixiacom.com +81 3 5365 4690 For the online support form, go to: http://www.ixiacom.com/support/inquiry/
Japan
Ixia KK Aioi Sampo Shinjuku Building, 16th Floor 3-25-3 Yoyogi Shibuya-Ku Tokyo 151-0053 Japan
India
Ixia Technologies Pvt Ltd 2nd Floor, 19/1, Vithall Malya Road, Bangalore 560 001 India
Support: Support-India@ixiacom.com +91 80 22161000 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ ?location=india
Part No. 913-0969 Rev D July 21, 2010
ii
Aptixia IxAutomate User Guide, Release 6.90
Table of Contents
Chapter 1 Chapter 2 About this Guide Introduction
What is Aptixia IxAutomate? . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Whats New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 IxAutomate Menus and Tool Bars . . . . . . . . . . . . . . . . . . . . . 2-8
Chapter 3 Chapter 4
Creating and Running IxAutomate Tests Customizing the Test Environment
Configuring the IxAutomate Advanced Options . . . . . . . . . . 4-1 Advanced Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Configuring a Chassis Timing Source . . . . . . . . . . . . . . . . . 4-9 Inserting Custom User Code . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Running a Test Outside IxAutomate . . . . . . . . . . . . . . . . . . 4-12
Aptixia IxAutomate User Guide, Release 6.90 1
Table of Contents
Running IxAutomate Tests Unattended . . . . . . . . . . . . . . . 4-14
Chapter 5
RFC 2544 - IPv6 Benchmark Test Suite
Overview of the RFC 2544 - IPv6 Benchmark Test Suite . . 5-1 Back-to-Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27 Troubleshooting the RFC 2544 Tests. . . . . . . . . . . . . . . . . 5-40
Chapter 6
RFC 2889 Test Suite
Run Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 Address Cache Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6 Address Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 Back-Pressure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 Broadcast Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13 Head of Line Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14 Frame Error Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16 Fully-Meshed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Table of Contents
Many-to-Many Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22 Many-to-One Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25 One-to-Many Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27 Partially-Meshed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Chapter 7
Advanced Tcl Script Suite (ATSS)
Run Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Setting Up the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7 DTM Random Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 Flow Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 IP Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 Layer 2/Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17 Multiple Frame Sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26 Throughput NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29 IP Time to Live . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34 VLAN Broadcast Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 7-35 VLAN Meshed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37 VLAN One to Many . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40
Table of Contents
Traffic Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-42 Mixed IPv4-IPv6 Throughput Test . . . . . . . . . . . . . . . . . . . 7-46 All Mesh Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-49 VLAN Forwarding Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-56
Chapter 8
Multi-port Advanced Test Suite (MATS)
Run Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 Data Integrity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3 Frame Size Verify Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 Gap Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6 Pattern Verify Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7 Port Loss Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9 Random Frame Size Test . . . . . . . . . . . . . . . . . . . . . . . . . 8-10 Sequence Verify Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Chapter 9
IP Multicast (RFC 3918) Test Suite
Overview of the IP Multicast (RFC 3918) Test Suite . . . . . . 9-1 Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9 Accumulated Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16 Aggregated Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Table of Contents
Distributed Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24 Group Capacity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27 Group Join Delay Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31 Group Leave Delay Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36 Latency Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-40 Mesh Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-45 Throughput No Drop Rate Test . . . . . . . . . . . . . . . . . . . . . 9-49 Mixed Class Throughput Test . . . . . . . . . . . . . . . . . . . . . . . 9-55 Scale Group Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-60 Tunneling Throughput Test . . . . . . . . . . . . . . . . . . . . . . . . . 9-64 Burdened Latency Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-74 Burdened Group Join Delay Test . . . . . . . . . . . . . . . . . . . . 9-78
Chapter 10 IPv6 Tunneling Test Suite

Tunnel Capacity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Tunnel Frame Loss Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Tunnel Throughput Test . . . . . . . . . . . . . . . . . . . . . . . . . . 10-12 Configuring the Protocol and Tunnel Parameters . . . . . . . 10-17 Sample DUT Configurations . . . . . . . . . . . . . . . . . . . . . . . 10-26
Table of Contents
Chapter 11 Quality of Service (QoS) Test Suite

Run Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1 VLAN Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1 Many-to-One Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6 One-to-Many Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7 Flow Ratio Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Chapter 12 Layer 2 VPN Test Suite

Overview of the Layer 2 VPN Test Suite . . . . . . . . . . . . . . 12-2 DUT Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2 LDP Egress Performance Test . . . . . . . . . . . . . . . . . . . . . 12-5 LDP IMIX Performance Test . . . . . . . . . . . . . . . . . . . . . . 12-11 LDP Ingress Performance Test . . . . . . . . . . . . . . . . . . . . 12-21 LDP Partially-Meshed Performance Test . . . . . . . . . . . . 12-27 Martini Sessions Scalability Test . . . . . . . . . . . . . . . . . . . 12-37 Virtual Circuits Scalability Test . . . . . . . . . . . . . . . . . . . . 12-43
Chapter 13 Layer 3 VPN Test Suite

Overview of the Layer 3 VPN Test Suite . . . . . . . . . . . . . . 13-1 DUT Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Table of Contents
Performance and Scalability Test . . . . . . . . . . . . . . . . . . . . 13-7
Chapter 14 VPLS Test Suite

Overview of the VPLS Test Suite . . . . . . . . . . . . . . . . . . . . 14-1 DUT Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 VPLS and Run Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14-7 Partially-Meshed Throughput . . . . . . . . . . . . . . . . . . . . . . 14-13 Peer-to-Peer Throughput . . . . . . . . . . . . . . . . . . . . . . . . . 14-18 Address Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22 Address Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
Chapter 15 Label Distribution Protocol (LDP) Test Suite

Overview of the Label Distribution Protocol (LDP) Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2 DUT Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3 Egress Partially Meshed Performance Test . . . . . . . . . . . . 15-4 Egress Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . 15-11 Ingress Partially Meshed Performance Test . . . . . . . . . . . 15-18 Ingress Performance Test . . . . . . . . . . . . . . . . . . . . . . . . 15-24 Transit Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . 15-30
Table of Contents
Chapter 16 Resource Reservation Protocol (RSVP) Test Suite

Overview of the Resource Reservation (RSVP) Test Suite 16-1 Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3 Label Capacity Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6 LSP Cutover Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11
Chapter 17 OSPF Test Suite

Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1 OSPF Convergence Test . . . . . . . . . . . . . . . . . . . . . . . . . 17-3 OSPF Route Capacity Test . . . . . . . . . . . . . . . . . . . . . . . 17-11 OSPF Route Convergence Test . . . . . . . . . . . . . . . . . . . 17-16 OSPF Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . 17-22
Chapter 18 Border Gateway Protocol (BGP) Test Suite

Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1 BGP Route Capacity Test . . . . . . . . . . . . . . . . . . . . . . . . . 18-3 BGP Route Convergence Test . . . . . . . . . . . . . . . . . . . . . 18-8 BGP Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . 18-15
Chapter 19 IS-IS Test Suite

Overview of the IS-IS Test Suite . . . . . . . . . . . . . . . . . . . . 19-1
Table of Contents
Setting Up the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1 ISIS Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-3
Chapter 20 STP Test Suite

Overview of the STP Test Suite. . . . . . . . . . . . . . . . . . . . . . 20-1 Setting Up the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1 STP Convergence Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3 MSTP Convergence Test . . . . . . . . . . . . . . . . . . . . . . . . . . 20-8
Chapter 21 Broadband Test Suite

Overview of the Broadband Test Suite . . . . . . . . . . . . . . . . 21-1 Setting Up the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-3 Broadband Throughput Test . . . . . . . . . . . . . . . . . . . . . . . . 21-7 Broadband Back-to-Back Test. . . . . . . . . . . . . . . . . . . . . . 21-11
Chapter 22 RFC 3511 Test Suite

Overview of the RFC 3511 Test Suite . . . . . . . . . . . . . . . . . 22-1 Setting Up the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-4 Test Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-8 IP Throughput Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-8 TCP Connections Capacity Test . . . . . . . . . . . . . . . . . . . . 22-12
Table of Contents
Maximum TCP Connection Establishment Rate Test . . . 22-14 Denial of Service Handling Test . . . . . . . . . . . . . . . . . . . . 22-17 HTTP Transfer Rate Test . . . . . . . . . . . . . . . . . . . . . . . . . 22-20 Maximum HTTP Transaction Rate Test . . . . . . . . . . . . . . 22-23 Illegal Traffic Handling Test . . . . . . . . . . . . . . . . . . . . . . . 22-26 IP Fragmentation Handling Test. . . . . . . . . . . . . . . . . . . . 22-30 Latency Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-34
Chapter 23 LACP Test Suite

Overview of the LACP Test Suite. . . . . . . . . . . . . . . . . . . . 23-1 Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2 Port to LAG Throughput Test . . . . . . . . . . . . . . . . . . . . . . 23-13 LAG to LAG Throughput Test. . . . . . . . . . . . . . . . . . . . . . 23-17 LAG to LAG Link Drop Test . . . . . . . . . . . . . . . . . . . . . . . 23-21
Chapter 24 MEF14 Test Suite

Overview of the MEF14 Test Suite. . . . . . . . . . . . . . . . . . . 24-1 Setting Up the Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-8 Frame Delay, Frame Delay Variation, Frame Loss Ratio Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24-11 Bandwidth Profile Rate Enforcement Test . . . . . . . . . . . . 24-17
10 Aptixia IxAutomate User Guide, Release 6.90
Table of Contents
Bandwidth Profile per Ingress UNI Test. . . . . . . . . . . . . . . 24-20 CIR and EIR Combined Test . . . . . . . . . . . . . . . . . . . . . . . 24-23 Bandwidth Profile per CoS Test. . . . . . . . . . . . . . . . . . . . . 24-27 Multiple Bandwidth Profiles at the UNI Test . . . . . . . . . . . 24-31
Chapter 25 Triple Play Test Suite

Overview of the Triple Play Test Suite. . . . . . . . . . . . . . . . . 25-1 Scalability Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-2 Setting Up the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-3 Pass/Fail Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-25 Test Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-28 Test Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25-29
Chapter 26 Enhanced Quality of Service Test Suite

Setting Up the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-2 Layer 2 QoS Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-7 Layer 3 QoS Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-11 MPLS OSPF QoS Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-16 MPLS QoS Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-21
11
Table of Contents
Chapter 27 Internet Infrastructure Test Suite

IP Mesh Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27-1
Chapter 28 Fibre Channel over Ethernet Test Suite

Overview of the Fibre Channel over Ethernet Test Suite . . 28-1 FCoE Performance Test. . . . . . . . . . . . . . . . . . . . . . . . . . . 28-2 Mixed Class Throughput Test . . . . . . . . . . . . . . . . . . . . . 28-29 PFC Throughput Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28-34
Chapter 29 Metro Performance Test Suite

Data Plane Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29-1 QoS Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29-19
Chapter 30 IxGreen Test Suite

Test System Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30-2 Test Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30-2 Test Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30-7 Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30-7
Appendix A Tcl/Tk License

Tcl/Tk License Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
12
Table of Contents
Appendix B Ixia License Management

Types of Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-2 Installation Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B-5 License Installation Example. . . . . . . . . . . . . . . . . . . . . . . . .B-7
Appendix C StatViewer Support

StatViewer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .C-1 Supported StatViewer Features . . . . . . . . . . . . . . . . . . . . . .C-1
Appendix D Diagnostics Support

Diagnostics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-1 Using Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .D-2
13
Table of Contents
14
1
Purpose Manual Content
Section Chapter 1, About this Guide
Chapter 1:
About this Guide
The information in this section is provided to help you navigate through this manual and make better use of its content. A list of related documentation is also included. It provides information about Aptixia IxAutomate theory, features, functions, and options, as well as additional test setup details. This manual contains the following sections:
Description Provides information about this manual, including its purpose, content, and related documentation. It also explains how to contact technical support. Explains what the Aptixia IxAutomate product is, describes what is new in the current release, as well as the menus and tool bars. Describes the tasks required to create and run an IxAutomate test. Describes the more advanced features that enable you to customize your IxAutomate test environment. Describes the RFC 2544 test suite. Describes the RFC 2889 test suite. Describes the Advanced Tcl Script Suite tests. Describes the Multi-port Advanced test suite. Describes the IP Multicast test suite. Describes the IPv6 Tunneling test suite.
Chapter 2, Introduction Chapter 3, Creating and Running IxAutomate Tests Chapter 4, Customizing the Test Environment Chapter 5, RFC 2544 - IPv6 Benchmark Test Suite Chapter 6, RFC 2889 Test Suite Chapter 7, Advanced Tcl Script Suite (ATSS) Chapter 8, Multi-port Advanced Test Suite (MATS) Chapter 9, IP Multicast (RFC 3918) Test Suite Chapter 10, IPv6 Tunneling Test Suite
1-1
About this Guide
Section Chapter 11, Quality of Service (QoS) Test Suite Chapter 12, Layer 2 VPN Test Suite Chapter 13, Layer 3 VPN Test Suite Chapter 14, VPLS Test Suite Chapter 15, Label Distribution Protocol (LDP) Test Suite Chapter 16, Resource Reservation Protocol (RSVP) Test Suite Chapter 17, OSPF Test Suite Chapter 18, Border Gateway Protocol (BGP) Test Suite Chapter 19, IS-IS Test Suite Chapter 20, STP Test Suite Chapter 21, Broadband Test Suite Chapter 22, RFC 3511 Test Suite Chapter 23, LACP Test Suite Chapter 24, MEF14 Test Suite Chapter 25, Triple Play Test Suite Chapter 26, Enhanced Quality of Service Test Suite Chapter 27, Internet Infrastructure Test Suite Chapter 28, Fibre Channel over Ethernet Test Suite Chapter 29, Metro Performance Test Suite Chapter 30, IxGreen Test Suite Chapter C, StatViewer Support Chapter D, Diagnostics Support Appendix A, Tcl/Tk License Appendix B, Ixia License Management Index
Description Describes the Quality of Service test suite. Describes the Layer 2 VPN test suite. Describes the Layer 3 VPN test suite. Describes the Virtual Private LAN Services test suite. Describes the Label Distribution Protocol test suite. Describes the Resource Reservation Protocol test suite. Describes the Open Shortest Path First protocol tests. Describes the Border Gateway Protocol tests. Describes the Intermediate System to Intermediate System (IS-IS) protocol test. Describes the Spanning Tree Protocol test and the Multiple Spanning Tree Protocol test. Describes the tests for Broadband Access Devices. Describes the RFC 3511 test suite. Describes the LACP test suite. Describes the MEF14 test suite. Describes the Triple Play Scalability test. Describes the Enhanced QoS test suite. Describes the Internet Infrastructure IP Mesh test. Describes the Fiber Channel over Ethernet (FCoE) test suite. Describes the Metro Performance test suite. Describes the IxGreen test suite. Describes what the StatViewer represents and lists the supported features. Describes the Diagnostics tool. Describes the Tcl/Tk License terms. Describes the licensing process, the installation scenarios, providing a license installation example. Is an index of terms in the manual.
1-2
About this Guide
Related Documentation
The following manuals may be helpful in learning more about Aptixia IxAutomate. The manuals are available on the CD shipped with the application, as well as on the Ixia Web site, at www.ixiacom.com. Aptixia IxAutomate Getting Started. Explains how to run a simple test and quickly gain experience with IxAutomate and includes explanations for the various IxAutomate capabilities. Aptixia IxAutomate SDK Plug-In Manual. Provides you with a guide to manually creating the key Tcl files required to implement a Plug-in test and facilitates the creation of new tests within the IxAutomate framework.
In addition to these manuals, Aptixia IxAutomate context-sensitive online Help is available. By pressing F1 or the applications Help button, you can view information about the displayed application window. Online Help content can also be accessed from the online Help table of contents or index.
Technical Support
You can obtain technical support for any Ixia product by contacting Ixia Technical Support by any of the methods mentioned on the inside cover of this manual. Technical support from Ixias corporate headquarters is available Monday through Friday from 6 a.m. to 6 p.m., Pacific Standard Time (excluding American holidays). Technical support from Ixias EMEA and India locations is available Monday through Friday, 8 a.m. to 5 p.m. local time (excluding local holidays).
1-3
About this Guide
1-4
Chapter 2:
Introduction
This chapter covers the following topics: What is Aptixia IxAutomate? on page 2-1. Whats New in This Release on page 2-6. IxAutomate Menus and Tool Bars on page 2-8.
What is Aptixia IxAutomate?

Aptixia IxAutomate is a sophisticated graphical user interface that you can use to run ready-made tests. Having ready-made tests allows you to quickly run tests, without supplying large amounts of complex configuration information.
2-1
Introduction
Figure 2-1.
IxAutomate
2-2
Introduction
IxAutomate relieves you of the need to learn the Tcl language used to write the scripts, while still enabling you to quickly and easily configure variables and parameters to suit a particular Device Under Test (DUT). You can configure, run a test, and save it for later reuse. The supplied tests include some tests that can be applied to a wide range of devices, and others intended for specific types of equipment. Combined with the Ixia family of chassis and Load Modules, you can use IxAutomate to create a test environment tailored to your specific requirements. You can use IxAutomate to test multi-layer 10/100 Mb/s Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet, and Packet over Sonet switches, routers, and networks. IxAutomate runs under Windows, UNIX, or Linux. This section covers the following topics: What is Tcl? on page 2-3. What if I want to write my own Tcl scripts? on page 2-3. Which tests are available with IxAutomate? on page 2-4. Online Help on page 2-4.
What is Tcl?
IxAutomates scripts are written in Tcl (Tool Command Language). Tcl has gained popularity in recent years in the telecommunications industry for the following reasons: Low cost: Tcl can be downloaded free of charge from the Internet. Simplicity: Tcl does not have complicated data structures or memory management schemes. All data types are strings, which makes it very simple to use. Easy to learn: The Tcl syntax resembles that of C/C++, the most widely used programming language, which makes Tcl very easy to learn. Cross-platform support: One of the biggest advantages of Tcl is the ability to run scripts on multiple platforms without modification. Tcl shells for running scripts are available for Microsoft Windows, Sun Solaris, Apple Macintosh, Linux, HP-UX, and several other operating systems. Wide variety of third-party tools: Tcl developers all over the world have created reliable software applications that can be obtained free of charge from the Internet. Extensions to Tcl are available for graphics, networking, World Wide Web applications, network management, and many others. If you decide to create your own Tcl applications, the large number of existing applications can speed up the development of your own applications. Non-compiled language: Because Tcl is not a compiled language, it is wellsuited to rapid prototyping and quick development of applications.
What if I want to write my own Tcl scripts?
Ixia supplies a complete suite of Tcl commands which you can use to access Ixia hardware. If you are familiar with Tcl, you can use these command to create your own test scripts and run them on Ixia hardware.
2-3
Introduction
Instead of supplying a set of C/C++ functions available only through the Tcl shell, Ixia enables you to control the hardware using native Tcl commands. The Ixia Tcl commands follow the methodology common to all Tcl extensions and observed by Tcl developers all over the world. Every effort has been made to design the structure of the commands so that they are straightforward and easy to use. For more information, see the Ixia Tcl Development Guide. You can create your own test by using the Plugin Generator Tool. For more information, see Aptixia IxAutomate SDK Plug-In Manual.
Which tests are available with IxAutomate? Online Help
For the list of test suites available in IxAutomate, see Chapter 1, About this Guide.
IxAutomate includes context-sensitive online help (Figure 2-2). While working with IxAutomate, if you press F1 or select Help | Help Topics from the menu bar, IxAutomate opens an HTML version of this guide. The help that displays depends on whether or not a test is selected in the Tests area: If a test is selected in the Tests area and you press F1 or select Help | Help Topics, IxAutomate opens the online help for that test. If no test is selected in the Tests area and you press F1 or select Help | Help Topics, IxAutomate opens a table of contents, allowing you to navigate to the section of the guide you want to read.
2-4
Introduction
To display the online help for a particular test, select the test, then press F1. If no test is selected, IxAutomate opens the table of contents for the online help. Figure 2-2. IxAutomate Online Help
2-5
Introduction
Whats New in This Release

This release includes the following new features or enhancements: New Features on page 2-6. Enhancements on page 2-6. The FCoE test suite (Chapter 28, Fibre Channel over Ethernet Test Suite) is enhanced to include a test for PFC Throughput. The IxAutomate core is enhanced to support: NGY-NP (2/4/8 port) LSM1000XMVCDC (4/8/12/16 port) - Support FCoE on 1GE LSM1000XMS12P (12 port) VMware Server 1.0.2 and 2.0 HSE Load Module (40GE/100GE/BERT LSM XMV1). The RFC 2544 (Chapter 5, RFC 2544 - IPv6 Benchmark Test Suite) is enhanced to allow you to specify the units for the Tx traffic rate and report unit rate used in the results. The RFC 2889 test suite (Chapter 6, RFC 2889 Test Suite) is enhanced to include the ability to send learning frames at the beginning of each iteration. The IP Multicast test suite (Chapter 9, IP Multicast (RFC 3918) Test Suite) is enhanced to support QinQ. The FCoE test suite (Chapter 28, Fibre Channel over Ethernet Test Suite) is enhanced to provide ability to: select multiple Non-FCoE frame sizes. This will allow the test iterations to be based on two frame size loops - one for Non-FCoE and the other for FCoE. record Pause Frame statistics for each iteration for each Tx port. enable jitter measurement (min /ave /max) enable fixed rate Tx for Non-FCoE traffic while FCoE traffic is incremental. The Advanced Test Option in RFC 2544 / 2889 / 3918 and ATSS is enhanced to include the Prime DUT options which run an additional iteration to allow the DUT to populate the forwarding table. This iteration is not included in the binary search results. IxAutomate is enhanced to support Windows Server 2008. IxAutomate is enhanced to support Windows 7. Flow control support added for the following test suites: ATSS Throughput test
New Features Enhancements
2-6
Introduction
RFC 2544 Throughput test RFC 2889 Many-to-One Throughput test RFC 2889 One-to-Many Throughput test The following tests has been enhanced so that you can run the tests without dropping the link between ixia ports and connected device: ATSS Throughput test ATSS All Mesh test All RFC 3918 tests IxGreen tests. The following tests are enhanced to include option to use the same Random MAC addresses between test: ATSS - Throughput ATSS - All Mesh RFC 2544 Test Suite RFC 2889 Test Suite (Fully Meshed, One to Many, Many to One and Partially Meshed Tests) The following tests are enhanced to include the option to perform the neighbor discovery process using Router Solicitation messages: OSPF Convergence OSPF Performance OSPF Route Capacity OSPF Route Convergence IxAutomate is enhanced to support TDM synchronization between multiple chassis. IxAutomate is enhanced to enable IxOS to propose the MAC address when the addressing mode is FPMA (Fabric Provided MAC Address).
2-7
Introduction
IxAutomate Menus and Tool Bars

This section briefly describes IxAutomate menus and tool bars. Figure 2-3 shows the IxAutomate main window. IxAutomate Main Window on page 2-8. File Menu on page 2-9. Run Menu on page 2-9. Tools Menu on page 2-9. Settings Menu on page 2-10. Help Menu on page 2-11.
IxAutomate Main Window

Menu Bar Navigation Bar: Allows you to choose what to display in the main work area of the IxAutomate user interface. Configurations Bar: Contains test templates, test user configurations, and user recent test configurations.
Tool Bar
Configure buttons bar: Allows you to choose which buttons to display in the left pane.
Elapsed test run time
MultiUser logon name
2-8
Introduction
Figure 2-3.
File Menu
New: Creates a new test. Save: Saves the current file. Delete: Deletes the selected file. Import Configuration: You can load a TCL setting file. The IxAutomate GUI loads the file containing the configuration file and refreshes its Config tree with the newly-added test, but does not copy it from the source. Import User Template: You can load a new test. The IxAutomate GUI loads the test Tcl files and refreshes its Test Suites tree of tests with the newly-added test. Save As: Saves the current file under a new name. You can use any characters except square brackets. Import Configs/Results: You can load a config directory and/or a result directory. The IxAutomate GUI loads: the TCL files and refreshes the Configurations pane while copying the files in the <installation path\Configs> the RES files and refreshes the Data Miner pane.The Exit: Exits IxAutomate. files are not copied from the source. Delete User Template: The correct path for importing Deletes the selected temthe configurations/results files plate. is: <installing path>\Configs / <installing path>\Results. File Menu
Figure 2-4.
Run Menu
Start: Starts the current test.
Stop: Stops the current test. Figure 2-5. Run Menu
Tools Menu
Launch Generator: Allows you to open the tool that helps you create your own tests. For more information, see the Aptixia IxAutomate SDK Plug-In Manual.
License Server: Allows you to enter the Plugin Generator License Server name or its IP address. For more information, see the Aptixia IxAutomate SDK Plug-In Manual.
2-9
Introduction
Figure 2-6.
Tools Menu User Template Generator Options Horizontal Views Layout: You can group views in 2 rows. In each row, you can resize the contained views. You can even resize each row. Vertical Views Layout: You can group views in 2 columns. In each column, you can resize the contained views. You can even resize each column.
Test Results Picker: Displays the Test Results Selection window. It allows you to choose what views to replay or compare. Figure 2-7.
Switch To Real-Time Mode: Allows you to display the graphics in real-time mode.
Tools Menu Stat Viewer Options
Settings Menu
Preferences: Enables you to modify aspects of IxAutomates behavior to suit your preferences. See Configuring the IxAutomate Advanced Options on page 4-1. Defaults: Enables you to modify default IxAutomate settings to suit your preferences. See Configuring the IxAutomate Advanced Options on page 4-1. Figure 2-8. Settings Menu
2-10
Introduction
Help Menu
HelpTopics: IxAutomate opens the table of contents for the online help. If a test is selected, the online help for that test displays. Licensing: It allows you to choose where to install the license: on the chassis or on a license server. Diagnostics: It allows you to collect variable, internal information from a chassis and client machine, and wrap them into a ZIP file, for transmission to Ixia. This option is not available while running a test.
About: Displays the IxAutomate version number. Figure 2-9. Help Menu
2-11
Introduction
2-12
Chapter 3:
Creating and Running IxAutomate Tests
This section describes tasks required to create and run an IxAutomate test. The main topics in the section are as follows:
Step 1 2 Topic Topic Description: Instructions for connecting to the DUT and starting the application Explanation of and instructions for creating your own tests based on the IxAutomate library of test templates Instructions for selecting and setting up the ports that you include in your tests Explanation of and instructions for setting up a traffic map for your tests Instructions for defining the Frame Data for your test traffic. This largely involves defining addresses, based on the protocols that you are using in your tests Instructions for selecting the frame sizes to use in your test traffic Explanation of the iterations, trials, and durations that you set for your test runs Explanations on how to customize your test environment using the basic and advanced options and also the custom user code Explanations on how to set up the IxAutomate test statistics and graphics Explanations of how to enter commands and their arguments to configure the DUT
Starting a Test Session on

page 3-2
Creating Your Tests on

page 3-3
3 4 5
Setting Up Ports on page 3-7 Setting Up the Traffic Map on page 3-11 Configuring IP, IPX, and MAC Addresses on page 3-18 Choosing Frame Sizes on page 3-45 Setting Up the Test Run Parameters on page 3-51 Configuring the IxAutomate Test Setup Options on page 3-53 Setting Up the StatViewer Statistics on page 3-56 Setting Up the Device Under Test (DUT) Parameters on page 3-57
6 7 8
9 10
3-1
Step 11 12
Topic Running a Test on page 362 Obtaining Test Output on page 3-69
Topic Description: Explanations of how to run a test Explanation of the various types of output that you obtain from your tests
Note: There are a few tests where the procedures for selecting, mapping, or addressing ports are different from those described in this section. Those unique procedures are described in the corresponding tests.
Related Information
The more advanced (and generally optional) IxAutomate tasks are described in Customizing the Test Environment on page 4-1. For a description of the controls on the IxAutomate menus and tool bars, refer to IxAutomate Menus and Tool Bars on page 2-8.
Step 1: Starting a Test Session
This section describes tasks you typically do at the beginning of a test session. The major topics covered in this section are: Connect the DUT to the Ixia Hardware on page 3-2 Start IxAutomate on page 3-2
Connect the DUT to the Ixia Hardware
If you have not already done so, connect the DUT ports to the Ixia chassis, as shown in Figure 3-1. Make sure that you use the correct cables to connect the DUT ports to compatible Ixia ports.
Figure 3-1.
Ixia Chassis DUT Cable Connection
Start IxAutomate
See the following topics for instructions on starting IxAutomate: Starting IxAutomate under Windows on page 3-3. Starting IxAutomate under Linux and Unix on page 3-3.
3-2
Starting IxAutomate under Windows

The installation process adds an icon for IxAutomate on your desktop (Figure 32).
Figure 3-2.
IxAutomate Icon
Double-click the IxAutomate icon on the desktop.

Note: If you have configured Windows to use Large Fonts, IxAutomate may not display properly. IxAutomate is optimized for display at Windows default font setting, Small Fonts. If you set Font Size to Large Fonts, some IxAutomate controls may display crowded together or pushed off their windows.
Starting IxAutomate under Linux and Unix

Running IxAutomate under Linux or Unix requires two components: the IxAutomate application that runs on the client system, and a IxTclServer application that (typically) runs on the Ixia chassis. 1. Create the test configurations you want to run in a text editor and then save it as <test_name.tcl> file. For more details, see When Running Under Linux and Unix: on page 3-3. 2. Run the test using the command below:
$IXIA_HOME/bin/ixwish <test_name.tcl>
Note: IxAutomate does not have a GUI when installed under Linux/Unix; however, all the test configurations created in Windows run under Linux or Unix with minor adjustments (for example, change the installation path).
Step 2: Creating Your Tests
When Running Under Linux and Unix:

All IxAutomate tests come with a sample configuration file in the form of: testname-sample-cfg.tcl. The path where the sample configurations are installed in is: $IXIA_HOME/lib/IxAutomate/Configs. To create your tests: 1. Rename the sample-cfg.tcl file to your test name. 2. Open the new configuration file with a text editor and modify the parameter settings for this test. 3. Alternatively, you may wish to configure your test using the Windows GUI, and then copy this configuration file to your Linux/Unix machine to run tests.
3-3
When Running Under Windows:

The IxAutomate main window opens (Figure 3-3) when you double-click the IxAutomate icon.
Navigation bar Configurations bar
Figure 3-3.
The Navigation bar on the left side determines what to display in the main work area of the IxAutomate user interface. The Navigation bar contains the following buttons: Configuration if you click this button, IxAutomate displays the Configuration tree and the window corresponding to the selected item. You can use these two elements to configure and run a test. Logs if you click this button, IxAutomate displays the Test Run log and the DUT Setup log from a running or completed test. Statistics if you click this button, IxAutomate displays StatViewer, which allows you to view statistics from a running or completed test. Batch Scheduler if you click this button, IxAutomate displays the scheduling window, which allows you to automatically run different test configurations at a specified time and date.
3-4
Data Miner if you click this button, IxAutomate displays a table run, containing the list with test runs for the selected test, and the contents pane including the logs, reports, csv files, and views for the selected test.
The Configuration bar on the right side contains three subpanes that allow quick access to frequently-used items: Templates contains the Base Templates list and the User Templates list. For more information about the tests available in the Base Templates list, see Chapter 1, About this Guide. Configurations contains the test configurations you created. Recent Tests contains the list with the tests you recently created.
Creating a New Test

To create a new test: 1. Select the desired test template from the Templates subpane. 2. Right-click the selected test template. A drop-down menu opens, as shown in Figure 3-4:
Figure 3-4.
New Test Option
3. Choose New Test option. The New Test dialog box opens (Figure 3-5 on page 3-6). Note that you can also create the new test by selecting New from the File menu (as an alternative to right-clicking the template name).
3-5
Figure 3-5.
New Test Dialog Window
4. A default name is available for the new test; you can also enter a different name for the test. 5. Click OK. IxAutomate creates a new test file, using the name you specified, and adds it to the Configs pane (Figure 3-6). You can now configure the test and run it.
Figure 3-6.
New Test on the Configurations Pane
Next Steps
Once you have created a new test, you need to set up the test to make it ready for execution. For detailed instructions on setting up a test, refer to the following sections of this manual: the chapter that is specific to the particular test you are setting up. Setting Up Ports on page 3-7 Setting Up the Traffic Map on page 3-11 Configuring IP, IPX, and MAC Addresses on page 3-18 Choosing Frame Sizes on page 3-45 Setting Up the Test Run Parameters on page 3-51 Configuring the IxAutomate Test Setup Options on page 3-53 Setting Up the StatViewer Statistics on page 3-56 Configuring the Test Statistics and Graphics Options on page 3-57
3-6
Setting Up the Device Under Test (DUT) Parameters on page 3-57
Step 3: Setting Up Ports
The Port Setup window (Figure 3-7) allows you to connect to the hardware resources (chassis), select and configure the ports that you use in the test you are setting up.
Figure 3-7.
Port Setup Window
The section up in the Port Setup window displays the chassis used in the current test and enables you: To add more chassis for testing, filling in the available fields in the displayed Add chassis dialog box (Figure 3-8). To delete the currently selected chassis from the list by using the Delete button. To connect the currently selected chassis in the chassis list by clicking Connect. To disconnect the selected chassis from the chassis chain by clicking Disconnect.
3-7
HostName: The name or IP address of the chassis you are adding to the chassis list. To add a new chassis, enter its host name or IP address. Chassis ID: The number identifying the chassis position in the chain. The Chassis IDs are automatically assigned with the first chassis as 1. If you want to connect to multiple chassis, they must be daisy-chained together through their sync-in and sync-out ports. OK: Click OK when Apply: Click Apply you have finished to add the chassis to adding chassis. the chassis list. Figure 3-8. Add Chassis Dialog Box
Time Source: Allows you to choose the time source for a chassis. The available options areInternal, GPS, and TDM. For more information, see Chapter 4, Configuring a Chassis Cable Length: Defines the length of the cable connecting the selected chassis to the previous chassis in line. Select the length from the list box. Selecting and incorrect length can adversely influence test results. Cancel: Cancel adding the chassis procedure.
The section in the bottom Port Setup window allows you to select and configure the ports that you use in the test that you are setting up. IxAutomate organizes chassis, cards, and ports hierarchically (similar to the way Windows Explorer organizes files, directories, PCs, and networks). You can use similar controls to expand (the plus sign, +) and collapse (the minus sign, -) items. The Chassis Name is the highest level of the hierarchy. All cards of that chassis are grouped under a single heading (the Chassis name heading). Next, under each card, IxAutomate displays individual ports. See Figure 3-9.
Chassis Name 1 Click here to select all cards on chassis 1 Card 1 Click here to select all ports on card 1 Port 1 Port 2 Click here to select a specific port on card 1 on chassis 1 Port 3 Port 4 Card 2 Chassis Name 2 Chassis Level Card Level Port Level
Figure 3-9.
Port Setup Explorer View Display Levels
Changing Port Properties

If you select a card type, chassis, card, or individual port, IxAutomate displays the properties of those port(s) on the Settings area in the right side of the window. The item which you select determines how widely IxAutomate applies changes to port parameters. Changes apply to all ports at the current selection level. For example, if you select a card and change a port parameter, IxAutomate applies
3-8
the change to all the ports on that card. If you select a chassis and change a port parameter, it applies the change to all ports on that chassis. Use the following procedure to change port properties: 1. Choose the desired device (for example, an individual port or a card). 2. In the Settings area of the window, change any of the parameters as appropriate. For the ATM cards, the ATM header parameters available to be set are listed in Table 3-1.
Table 3-1. Parameter Encapsulation ATM Header Parameters Description The type of RFC 2684 multiplexing encapsulation used. You can select one of the following: LLC Bridged Ethernet/802.3 LLC Bridged Ethernet/802.3 no FCS VC MUX Bridged Ethernet/802.3 VC MUX Bridged Ethernet/802.3 no FCS VPI VCI GFC Virtual Path Identifier Virtual Circuit/Connection Identifier Generic Flow Control, for device control signaling. Uncontrolled equipment uses a setting of 0000 (Null value). Cell Loss Priority setting for this stream queue/VC. Used to set discard priority level for ATM cells. A CLP value = 0 has higher priority than a CLP value = 1.
CLP
For the Gigabit over Copper ports (Copper1000), you can set the auto negotiation of master/slave options. The Enable Negotiate Master/Slave check box allows you to enable or disable the auto negotiation; when it is disabled, master or slave can be manually selected. This option is disabled for ports other than gigabit over copper. The RFC 2544 Throughput test and the ATSS Throughput test support, for the Joshua Tree VCAT, two-port operation modes: OC48 Concatenated the VCAT support is not used, resulting in common behavior and functionality as for a normal POS port. OC48 Channelized the port switches to VCAT mode, therefore supporting multiple circuit configuration. IxAutomate is not configuring ports in the Channelized mode, allowing you to load a port configuration file generated by IxExplorer. When the test runs, the configuration file is imported at the port setup time, before the addresses and streams are written on the ports. IxAutomate supports multiple circuit configurations but uses only one circuit per port.
3-9
In the Channelized mode, two settings are available: Config File allows you to set a port configuration file generated in IxExplorer. This file is needed to configure the circuits on the port and it is not validated until test runtime. Circuit Index allows you to select the circuit to be used by IxAutomate. The default value is 1, which represents the first circuit configured on the port. Since there is no validation of the file until runtime, this setting is not validated either until then.
OAM Ethernet Support

The OAM Ethernet defines the operations, administration, and maintenance sublayer. It provides network operators with the ability to monitor the health of the network and quickly determine the location of failing links or fault conditions. The OAM sub-layer works on any Ethernet technology and provides the following functions: Discovery Link performance monitoring Fault detection and fault signaling Loopback testing MIB (Management Information Base) variable retrieval Organization specific enhancements
The OAM protocol data units are normal Ethernet frames with fixed multicast destination address (01:80:C2:00:00:02) and EtherType (0x8809). Table 3-2 lists the available OAM parameters. They can be set for each port. The settings for the OAM options are saved in the Tcl configuration file so that they be available to the test engine.
Table 3-2. Parameter MAC Address Loopback OAM Ethernet Parameters Description Specify the MAC Address for the selected port. The loopback port capabilities are available if this option is enabled. By default, this option is not enabled. The link events port capabilities are available if this option is enabled. By default, this option is not enabled. Specify the maximum OAM protocol data unit (PDU) size. The default value is 1518. Specify the organization unique identifier. The default value is 00 00 00.
Link Events
Max OAM PDU size OUI
3-10
Table 3-2. Parameter
OAM Ethernet Parameters (Continued) Description Specify the vendor specific information.The default value is 00 00 00 00. If no OAM PDUs are received in the specified interval, the local OAM resets the state machine. The default value is 5. If you enable this option, an optional Threshold Limit Values (TLV) can be sent with each information PDU. The type and value can be set for the TLV. Specify the TLV type. The default value is FE. Specify the TLV value.
Vendor Specific Info Idle Timer
Optional TLV
Type Value
Step 4: Setting Up the Traffic Map
You can use the Traffic Map area (Figure 3-10) of the Traffic Setup window to set up a traffic map for your test.
Figure 3-10. Traffic Map Area of the Traffic Setup Window
What is a Traffic Map?
A traffic map defines the transmit/receive relationship between the Ixia hardwares ports and DUTs ports. The traffic map determines which Ixia ports transmit traffic to the DUT, which ports receive traffic from the DUT, and which ports do both. IxAutomate can automatically create a traffic map for you, or you can create one manually. There are four types of traffic mapping: One-to-One mapping maps one transmit port to one receive port. One-to-Many mapping maps one transmit port to multiple receive ports. Many-to-One mapping maps multiple transmit ports to a single receive port.
3-11
Many-to-Many mapping maps all ports to all other ports for both receive and transmit.
The mapping types describe configurations from the point of view of the Ixia chassis. For example, one-to-many mapping refers to one Ixia transmit port being mapped to many Ixia receive ports. If a test does not support certain cards, IxAutomate skips those card types if it is creating the map (Automatic mapping) or does not allow you to select them if you are creating the map manually (Manual mapping).
One-to-One Mapping
In one-to-one mapping, one transmit port is mapped to one receive port. In the example shown in Figure 3-11, odd-numbered Ixia ports are assigned as transmit ports and even-numbered ports as receive ports. During a test, Ixia port 1 would transmit to DUT port 1 and the DUT would transmit from its port 2 to Ixia port 2.
Ixia tester
DUT
Figure 3-11. One-to-One Traffic Mapping
One-to-Many Mapping
In one-to-many mapping, one Ixia transmit port is mapped to multiple Ixia receive ports. Figure 3-12 on page 3-13 shows the traffic pattern in a one-tomany map: Ixia port 1 transmits to DUT port 1. DUT ports 2, 3, and 4 transmit to Ixia ports 2, 3, and 4.
3-12
Ixia tester
DUT
Figure 3-12. One-to-Many Traffic Mapping Note: If you are running a one-to-many test, do not mix Packet over Sonet ports (OC3, OC12, OC48 and OC192) with any other ports (such as 10/100/1000 Mb/ s ports) on the to-many side. All ports on the to-many side must be of the same type.
Many-to-One Mapping
In many-to-one mapping, multiple transmit ports are mapped to a single receive port. For example, in Figure 3-13, Ixia ports 1, 2, and 3 transmit to DUT ports 1, 2, and 3. The DUT transmits from its port 4 to Ixia port 4.
Ixia tester
DUT
Figure 3-13. Many-to-One Traffic Mapping Note: If you are running a many-to-one test, do not mix Packet over Sonet ports (OC3, OC12, OC48 and OC192) with any other ports (such as 10/100/1000 Mb/ s ports) on the from-many side. All ports on the from many side must be of the same type.
3-13
Many-to-Many Mapping
A many-to-many mapping is a fully-meshed configuration; multiple transmit ports are mapped to multiple receive ports. For example, in Figure 3-14, Ixia port 1 transmits to DUT port 1. The DUT transmits on its ports 2, 3, and 4 to Ixia ports 2, 3, and 4. At the same time, Ixia port 2 transmits to DUT port 2, which forwards back on its ports 1, 3, 4 to Ixia ports 1, 3, and 4. Ports 3 and 4 work similarly.
Ixia tester
DUT
Figure 3-14. Many-to-Many Traffic Mapping Note: If you are running a many-to-many test, do not mix Packet over Sonet ports (OC3, OC12, OC48 and OC192) with any other ports (such as 10/100/ 1000 Mb/s ports) on either side. Ports must be of the same type on each side.
How do I decide which traffic mapping to use?

The procedures for each test describe the type of mapping the test requires.
Configuring the Traffic Map
To Configure a Traffic Map:

1. Click the Traffic Setup option in the Configurations pane. The controls for configuring a traffic map are in the Traffic Map area (Figure 3-15) of the window. The available controls depend on whether you are creating an Automatic map or a Manual map.
3-14
Mode: Selects how the traffic map is to be created. Choose Automatic to have IxAutomate create the map, or Manual to create the map yourself.
Figure 3-15. Automatic/Manual Traffic Map Controls
2. Choose one: If you want to use Automatic mapping, allowing IxAutomate to assign the ports, select Automatic from the Mode list box. If you want to create a Manual traffic map and assign the ports yourself, select Manual from the Mode list box.
Note: You cannot create a Manual traffic map for many-to-many mapping, because all ports transmit and receive to all other ports.
3. Choose one: If you are configuring an automatic map, continue with To Configure an Automatic Traffic Map: on page 3-15. If you are configuring a manual map, continue with To Configure a Manual Traffic Map: on page 3-17. To Configure an Automatic Traffic Map: If you have already performed the steps listed under To Configure a Traffic Map: on page 3-14 and selected a Automatic map, follow the steps in this procedure to continue configuring the map. 1. Use the Direction field to specify the direction of traffic flow for the ports. If the ports transmit only or receive only, select Unidirectional. If the ports both transmit and receive, select Bidirectional.
3-15
Direction: Defines whether ports transmit only, receive only, or transmit and receive. Choose Unidirectional to restrict the port to transmit only or receive only. Choose Bidirectional to allow the port to transmit and receive. From: Specifies the first port in the range to start mapping from. The three fields correspond to the chassis, card and port number. To: Specifies the last port in the range to include in the map.
Exclude Ports: If you are configuring an automatic map and have defined the port range, click this button if you want to prevent certain ports within the range from being mapped. Echo Map: This option allows you to use the same port for both transmit and receive on the RFC 2544 tests. It is only available for the following configuration: Protocol cannot be MAC Map type must be Automatic Direction must be Unidirectional
Figure 3-16. Automatic Traffic Map Window
2. In the From field, specify the first port in the port range to be mapped. The controls select, from left to right, chassis, card, and port. 3. In the To field, specify the final port in the port range to be mapped. 4. If you want to prevent certain ports within the range from being mapped, click Exclude Ports.
2. Click ADD.
To exclude a port: 1. Select a port in the PORT list.
3. When you finish selecting ports, click APPLY to exclude them from the map. Figure 3-17. Auto Map Exclude Ports Dialog
3-16
5. To exclude a single port, select the port. To exclude all the ports on a card, select the card. To exclude all the cards in a chassis, select the chassis. 6. Click Add to add the ports to the list of excluded ports. If you change your mind and want to include an excluded port, card, or chassis, select it in the Excluded Ports list and click Remove. 7. After you have selected all the ports you want to exclude, click Apply. To Configure a Manual Traffic Map: 1. If you have already performed the steps listed under To Configure a Traffic Map: on page 3-14 and selected a Manual map, click the Configure button to display the Manual Port Map window (Figure 3-19 on page 3-17).
Configure: Displays the Manual Port Map window.
Figure 3-18. Manual Traffic Map Window
Use the Manual Port Map window to map the transmit and receive ports to each other.
2. Click on the corresponding port (or ports, 3. Click ADD. IxAutomate adds the mappin for one-to-many) in the Destination Port: list. and moves to the next logical choice. The window name contains also the type of mapping the test uses. To add a map entry: 1. Click on the port (or ports, for many-toone) in the Source Port: list.
4. When you finish mapping ports, click APPLY to create the map. Figure 3-19. Manual Map Configuration Dialog
3-17
2. Click a port in the Source Port: list. If the traffic map is many-to-one, click each port that you want to use on the many side. 3. Click the corresponding port in the Destination Port: list. If the traffic map is one-to-many, click each port that you want to use on the many side.
Note: In many-to-one and one-to-many mappings, the same port cannot be both a source port and a destination port at the same time.
4. Click Add. IxAutomate adds the mapping and moves the selection bar to the next logical choice: For one-to-one mappings, IxAutomate selects the next available source and destination ports. For one-to-many mappings, the source port remains the same and IxAutomate selects the next available destination port. For many-to-one mappings, it selects the next available source port and the destination port remains the same. 5. If you change your mind and want to include an excluded port, card, or chassis, select it in the Configured Maps list and click Remove. 6. When you finish mapping ports, click Apply to create the map.
Step 5: Configuring IP, IPX, and MAC Addresses
You use the Traffic Setup window (Figure 3-20 on page 3-19) to configure frame data (port addresses) and learning frames for your test. This step describes how to configure the port addresses that handle Layer 2 and Layer 3 traffic and learning frames. You should configure the port addresses only after you have configured the traffic map (as described in Setting Up the Traffic Map on page 3-11).
Note: You must configure the DUT to accept and forward frames generated for the protocols you use.
IxAutomate tests support one or more of the MAC, IP, IPX, and IGMP protocols. The port addresses you assign depend on the protocol you use: IP: If you use IP (IPv4 or IPv6), you must assign an IP address to each port. For IP layer tests, the fields in the Learning Frames pane set up the number of frames and rate for the ARP requests IxAutomate sends to the DUT ports, which respond with an ARP response containing their MAC addresses. IxAutomate decodes the ARP response and uses the DUT ports MAC address as the destination for streams transmitted from the Ixia ports during a test. IPX: If you use IPX, you must assign an IPX socket number to each port. For IPX, the fields in the Learning Frames pane set up the number of frames and rate for the RIPX requests sent to the DUT. You can send the Learn frames at the beginning of the test for each frame size, at the beginning of each trial, or
3-18
never. Also, after all the learn frames have been transmitted, you can insert a delay to allow the DUT to settle down after learning. MAC: If you use MAC, IxAutomate assigns default addresses for you. To help you identify the chassis, card and port IDs, IxAutomate inserts their IDs into the address. For MAC layer tests, IxAutomate sends simple Layer 2 frames containing the source MAC address.
To configure the protocol addresses and learning frames, use the controls in the Frame Data and Learning Frames areas of the Traffic Setup window (Figure 3-20 on page 3-19).
Figure 3-20. Protocol and Learning Frames Controls
Configuring MAC Addresses
When you run Layer 2 (MAC) tests, IxAutomate automatically assigns MAC addresses to all the ports. Once MAC addresses are assigned to each port, IxAutomate sends learn frames from all the receive ports in the traffic map to the DUTs ports. These learn frames contain the assigned MAC addresses (source addresses) of the receive ports and are sent as broadcasts. This allows the DUT to learn these addresses and store them in its MAC table. IxAutomate then sends the test traffic from the transmit ports to the receive ports of the Ixia chassis.
3-19
What are the default MAC addresses?

IxAutomate assigns the default MAC addresses based on the IDs of the chassis, card, and port. See Figure 3-21 on page 3-20. Reading from left to right and starting at byte 1 of the MAC address: Chassis ID: an eight-bit quantity using the least significant four bits of byte 3 and most significant four bits of byte 4. Card ID: a six-bit quantity using the least significant four bits byte 4 and most significant two bits of byte 5 Port ID: a six-bit quantity using the least significant six bits of byte 5
8 bits 6 bits 6 bits
8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
0
1
E
2
0
3
0
4
1
5 Port ID
0
6
Chassis ID
Card ID
Figure 3-21. Position of Chassis, Card, and Port IDs Within Default MAC Address
Table 3-3 shows examples of default MAC addresses.

Table 3-3. Chassis ID 1 1 1 1 1 1 Default MAC Address Assignment Card ID 1 1 1 1 2 2 Port ID 1 2 3 4 1 2 Default MAC Address 00 DE B0 10 41 00 00 DE B0 10 42 00 00 DE B0 10 43 00 00 DE B0 11 44 00 00 DE B0 11 80 00 00 DE B0 11 81 00
What if I need to change the default MAC addresses?

The default MAC addresses should work for most test scenarios. If you need to assign different MAC addresses for some reason, you must edit the Tcl scripts; you cannot use IxAutomate to do this. If you need to edit a script, Ixia suggests that you create a copy of the original script and edit the copy. This preserves the original script in case you need to use it again later.
What options can I configure for the MAC protocol?

Figure 3-23 on page 3-22 shows the configuration options for the MAC protocol. You can:
3-20
Select the type of Ethernet frame Assign names to ports
Table 3-4 on page 3-21 and Figure 3-23 on page 3-22 describe the available Ethernet frame formats.
Select the format of the Ethernet frame transmitted.
Port Names: Click this button if you want to assign names to the ports. See Assigning Names to Ports on page 3-40
Figure 3-22. MAC Protocol Controls Table 3-4. Parameter Raw Ethernet Ethernet Type 0800 MAC Protocol Controls Description Novell proprietary frame format based on a preliminary release of the 802.3 specification. Ethernet II frame with Type field set to 0800. The Type field specifies the upper-layer protocol that is to receive the data after Ethernet processing is finished. 0800 is the value assigned to IP (Internet Protocol). Valid IP Checksum Random MAC Addresses Ethernet frame including a valid IP checksum calculated from the value in the DA IP Address field. This option is available when the protocol is set to MAC. If you select this option, MAC addresses are uniformly distributed over the network processors of a switch device. Save Random Seed This option is available if the Random MAC Addresses option is selected. If you select this option, the same random MAC addresses are used between tests. This option is available only for the following tests: ATSS - Throughput ATSS - All Mesh RFC 2544 Test Suite RFC 2889 Test Suite (Fully Meshed, One to Many, Many to One and Partially Meshed Tests).
3-21
Raw Ethernet (Novell 802.3)
Dest. M AC 6 bytes
Source M AC 6 bytes
Len 2 bytes
Payload 46 - 1500 bytes
FCS 4 bytes
Ethernet Type "0800" (Ethernet II)
Dest. M AC 6 bytes
Source M AC 6 bytes
0800 2 bytes
Payload 46 - 1500 bytes
FCS 4 bytes
Valid IP Checksum
Dest. M AC 6 bytes
Source M AC 6 bytes
0800 2 bytes
IP header with valid checksum 46 - 1500 bytes
Payload
FCS 4 bytes (Cells not to scale)
Figure 3-23. Ethernet Frame Formats Used by MAC Protocol
3-22
Configuring Learning Frames

The controls in the Learning Frames area (Figure 3-24 on page 3-25) of the Traffic Setup window configure the MAC-layer learning frames IxAutomate sends to the DUT. Learning frames enable the DUT to learn the addresses configured on the Ixia ports, and for the Ixia ports to learn the DUT ports addresses. If you are not testing Layer 2 functionality, you can configure IxAutomate not to send learning frames, to prevent them from affecting your test results. This is not the case with tests that inherently use a mixture of frame sizes within a trial, such as the ATSS Internet Mix (IMIX) tests. If you configure IxAutomate to send learning frames Once for an IMIX test, it sends learning frames only at the beginning of the test.
Note: If you are testing a Level 2 switch or using one in your test setup, you may have to adjust the length of your test trial or modify the switchs configuration so that its forwarding table does not time out before the test completes. For more information, see Effect of Trial Duration on Level 2 Switches on page 3-52.
Table 3-5 describes the Learning Frames parameters and Figure 3-24 on page 325 shows the Learning Frames controls.
Table 3-5. Parameter Frequency Learning Frames Parameters Description Choose how frequently IxAutomate sends learning frames during the test. Once per Test: IxAutomate sends learning frames only once, at the beginning of the test. Once per Framesize: IxAutomate sends learning frames each time it begins testing with a new frame size. On Trial: IxAutomate sends learning frames at the beginning of each trial. On Binary Search: IxAutomate sends learning frames at the beginning of each binary search algorithm. On Iteration: IxAutomate sends learning frames at the beginning of each iteration. Never: IxAutomate never sends learning frames. Send MAC Only If the protocol is IP, IPv6, or IPX, you can check this box to specify that the learning frames is the only form of discovery performed, and the test performs ARP (IP), neighbor discovery (IPv6), or RIPX (IPX). If you are testing static route configurations and layer 2 devices are part of the traffic path, you should enable Send MAC Only.
3-23
Learning Frames Parameters (Continued) Description If this option is enabled, the neighbor discovery process is performed using Router Solicitation messages. Otherwise, the neighbor discovery process is performed by sending a PING6 message and waiting for a Neighbor Advertisement message reply. By default, this option is selected. The option is enabled only when IPv6 or IP/IPv6 protocols are selected. This option is available for the following tests: OSPF Convergence OSPF Performance OSPF Route Capacity OSPF Route Convergence.
Send Router Solicitation
Wait Time Before Transmit Wait Time After Transmit No. of Frames Frame Size Rate Enable Fast Path
Specify the length of time in ms that IxAutomate pauses before starting to send the learning frames. Specify the length of time in ms that IxAutomate pauses after sending all the learning frames from all the ports. Specify the number of learning frames that IxAutomate sends from each port. Specify the size of the learning frames. Specify the rate at which IxAutomate sends learn frames to the DUT. Enables or disables fast path handling. If you check Enable Fast Path, you must also fill in the No. of Frames and Rate fields. For more information, see What is Fast Path? on page 3-25. If Fast Path is enabled, this field specifies the number of frames that IxAutomate sends before beginning normal testing. This field displays only if you enable Fast Path. If you enabled Fast Path, specify the rate (in Mb/s) at which to send learning frames.
No. of Frames
Rate
3-24
Figure 3-24. Learning Frames Controls
What is Fast Path?
Fast Path is a feature of most modern switches. Todays newest switches are very fast and do not rely on their processors to build their address learning tables (such as MAC and ARP tables). Processor-based lookup is slow, and switches that use it cannot transmit data at wire speed. Instead, after responding to ARP requests and filling in their ARP tables, most modern switches create a shortcut or a fast path in a local cache when they receive their first IP frames. If you enable Fast Path, then after the ARP requests are sent, the Ixia chassis transmits a number of IP frames (defined by the No. of Frames parameter) to the DUT. Then, the Ixia chassis transmits the IP validation traffic to measure the DUTs real performance. The controls for Fast Path are in the Learning Frames area of the Test Setup window. The controls are described in Table 3-5 on page 3-23. The Ixia chassis supports Fast Path on all MAC, IP, and IPX layers.
Configuring IP Addresses
If you are going to test a DUT using IP traffic, you must: Assign IP addresses to the DUT ports. Configure the DUT to perform whatever function it is that you are testing. For example, if you are testing routing, configure the DUT it forwards frames from the Ixia transmit ports to the Ixia receive ports.
When you are assigning IP addresses to Ixia ports, you must observe the following rules: An Ixia port and the DUT port that it transmits to must have addresses on the same IP subnet. An Ixia transmit port and its corresponding Ixia receive port must have addresses on different IP subnets.
Figure 3-25 shows an example of an IP address scheme for an Ixia chassis and a DUT (or Gateway) using a 255.255.255.0 subnet mask.
3-25
Ixia card DUT
Port 1
192.18.1.100
192.18.1.1
Port 1
192.18.2.100 Port 2
192.18.2.1
Port 2
192.18.3.100 Port 3
192.18.3.1
Port 3
Port 4
192.18.4.100
192.18.4.1
Port 4
Figure 3-25. Example of IP Addressing
In Figure 3-25, assume that the traffic map is configured so that: Ixia port 1 transmits to DUT port 1 DUT port 2 forwards traffic to Ixia port 2
An IP address scheme to accomplish this would: Assign Ixia port 1 and DUT port 1 addresses on the same IP subnet. In Figure 3-25 on page 3-26, these are 198.18.1.100 and 198.18.1.1, respectively. Assign Ixia port 2 and DUT port 2 addresses on the same subnet, but a different subnet from the port 1 subnet.
At the beginning of each test, IxAutomate sends ARP Request frames to the DUT. Unlike layer 2 learn frames that are sent only from the receive ports, ARP frames are sent on every port configured for the test. The ARP Requests contain the IP addresses of the Ixia ports and DUT ports.
.
Note: If the Ixia port has to respond to ARP requests from the DUT in the middle of a test, it may lose some packets. To prevent this, set the DUTs ARP timeout interval to a value which exceeds the test duration, and configure the test to send learning frames at the start of each trial.
When it receives the ARP Request, the DUT examines it, extracts the Ixia port IP and MAC addresses from it, and stores them in its ARP table. It then responds with an ARP Reply containing the MAC address for its own port. IxAutomate uses the MAC address to build the IP frames that it generates during testing.
3-26
Ixia card DUT MAC: E0 00 01 02 03 04
Port 1
MAC: 00 DE BB 01 00 00 IP: 192.18.1.100 MAC: 00 DE BB 01 01 00 IP: 192.18.2.100
ARP request
192.18.1.1 ARP response 192.18.2.1 ARP response
Port 1
Port 2
ARP request
Port 2
Port 3
MAC: 00 DE BB 01 02 00 IP: 192.18.3.100
ARP request
192.18.3.1 ARP response
Port 3
Port 4
MAC: 00 DE BB 01 03 00 IP: 192.18.4.100
ARP request
192.18.4.1 ARP response
Port 4
Figure 3-26. ARP on Ixia and DUT Ports
IP Multicast Tests and IGMP

The IP multicast tests require some additional configuration. See the IP multicast section for details.
How to Assign IP Addresses to Ports

The method that you use for assigning IP addresses to ports depends on the type of traffic map that you selected: If you selected an Automatic traffic map, IxAutomate automatically assigns IP addresses to ports. See Assigning IP Addresses Automatically on page 327. If you selected a Manual traffic map, you must assign IP addresses manually. See Manually Assigning IP Addresses on page 3-29.
Assigning IP Addresses Automatically If you selected an Automatic traffic map, IxAutomate assigns IP addresses automatically. You provide the IP addresses you want it to assign to the first Ixia port and the first ports gateway or DUT address, and specify which octet it should increment to create additional addresses. To create addresses, IxAutomate applies the value you enter for First Port Source Address to the first Ixia port, increments it by one, then applies the incremented value to the next Ixia port.
3-27
If you check the Increment Gateway IP Address box, it also increments the gateway/DUT address each time it increments an Ixia port address. The process repeats for each additional Ixia port and gateway/DUT port, using the previous ports IP address as a base. A ports ID (chassis, card, port number) determines its position within the list of Ixia ports, and consequently the address it receives. When IxAutomate creates a traffic map, it sorts the ports in the map in numerical order based on their IDs, and applies addresses to them in ascending order. On the DUT, you must configure the corresponding ports with the IP addresses that IxAutomate expects them to have. For example, using the default values and assuming four Ixia ports, four DUT ports, and incrementing gateway/DUT address, IxAutomate assigns the addresses listed in Table 3-6.
Table 3-6. Ixia Port ID 1,1,1 1,1,2 1,2,1 1,2,2 IP Addressing Example Address Assigned to Ixia Port 198.18.1.10 198.18.2.10 198.18.3.10 198.18.4.10 Expected Gateway/DUT Port IP Address 198.18.1.100 198.18.2.100 198.18.3.100 198.18.4.100
First Port Source Address: Specify the IP address IxAutomate assigns to the first (lowest-numbered) Ixia port. Mask Width: Specify the width, in bits, of the subnet mask applied to the IP addresses. The default is 24. This field is only displayed for certain tests.
Port Names: Click this button if you want to set the ports. See Assigning Names to Ports on page 3-40. First Port Gateway/DUT: Specify the IP address of the port on the DUT connected to the first Ixia port. If the ixia port must reach the DUT over a network, enter the IP address of the next hop from the Ixia port to the DUT.
Increment Gateway IP Address: If you check this box, IxAutomate increments First Port Gateway/DUT address along with the First Port Source Address.
Figure 3-27. IP Address Assignment, Automatic Mode
3-28
Manually Assigning IP Addresses If you selected a Manual traffic map, you must specify the port IP addresses manually. To manually assign IP addresses: 1. In the Protocol area of the Test Setup window, click the Per Port Settings button.
Per Port Settings: Click this button to manually configure port IP addresses.
Figure 3-28. IP Protocol Address Assignment, Manual Mode
IxAutomate displays the Port Names configuration window (Figure 3-29 on page 3-30). You can use the Explorer-style tree shown in Figure 3-29 on page 3-30 or you can use a tabular-formatted window. To use the tabular format, click the Table Format button.
3-29
In order to assign an IP address to a port: 1. Select a port from the list.
2. (Optional) Enter a name for the port.
3. Specify the IP address you want to assign to the port.
4. Specify the IP address of the DUT port or next-hop gateway connected to the selected Ixia port. 5. Specify the width, in bits, of the subnet mask applied to the IP addresses.
7. Click OK to apply your configuration to the port.
Click Table Format if you want to use a tabular-formatted window to apply the IP addresses.
Figure 3-29. Port Names Configuration Window
1. Select a port from the list. 2. If you want to assign a name to the port, enter a name in the Port Name field. Enter unique names for each port. 3. In the Source IP Address field, specify the IP address that you want to assign to the selected Ixia port. 4. In the Gateway/DUT field, specify the IP address of the gateway or DUT port connected to the selected Ixia port. 5. In the Mask Width field, specify the subnet mask that you want to apply to the IP addresses assigned to the ports. 6. Repeat Step 1 through Step 5 for all the ports to which you need to assign IP addresses. 7. When finished, click OK to apply the IP addresses to the ports.
3-30
Using the Table Format Window Figure 3-30 shows the Table Format window. You can enter data in the fields one at a time or use the buttons to copy and paste data to multiple fields.
Name: (Optional) Enter a name for the port. Ports: Check the boxes to select the ports to which you want to assign addresses. Ports are identified by CHASSIS, CARD, PORT. IP Address: Specify the IP address you want to assign to the port. Gateway/DUT: Specify the IP address you want to assign to the DUT port connected to the selected Ixia port. Mask Width: Specify the width, in bits, of the subnet mask applied to the IP addresses.
Figure 3-30. IP Protocol Window, Table Format
This dialog provides an alternate method for setting of the IP Address, Gateway/ DUT and Name of the ports in an Ixia system. Table 3-7 lists the button description available in the Table Format window.
Table 3-7. Button Postfix Names Clear Entries Copy Gateway Table Format Window Buttons Description Description Allows you to set postfix names for your ports. Unselects all ports on all pages of the window. Copies the IP address assigned to the Gateway/DUTs port to the Gateway/DUT port you selected.
3-31
Table 3-7. Button
Table Format Window Buttons Description (Continued) Description Allows you to increment the IP address assigned to the first selected port and assign the incremented IP address to the next selected port. If you click this button again, the process repeats using the previous ports IP address as base. Active IP/Gateway Octet determines which byte is incremented.
Increment IP
Increment Gateway
Allows you to increment the Gateway address assigned to the first selected port and assign the incremented Gateway address to the next selected port. If you click this button again, the process repeats using the previous ports Gateway address as base. Active IP/Gateway Octet determines which byte is incremented.
Select All Ports Select Ports of Current Page Clear Port Selection
Selects all ports on all pages of the window. Selects all ports on only the current page of the window. Unselects all ports on all pages of the window.
Configuring IPv6 Addresses
Some of the IxAutomate tests support IPv6. To configure IPv6, use the following procedure: 1. In the Traffic Setup window, select IPv6 as Protocol in the Frame Data section. IxAutomate displays the controls for configuring IPv6 addresses (Figure 331).
If you want to increment the DUT IPv6 addresses, click Increment DUT IP Address. Select the field in the IPV6 address to be incremented to create additional addresses. Figure 3-31. IPV6 Controls
Click Encode to configure IPv6 addresses for the Ixia and DUT ports
3-32
Two IPv6 addresses are displayed in this window: The First Port Source Address field displays the IPv6 address to apply to traffic from the first Ixia port in the port list. This address is the basis for the IPv6 addresses IxAutomate assigns to the other Ixia ports in the port list. To create addresses for the second and subsequent ports, IxAutomate increments the First Port Source Address. The First Port Gateway/DUT Address field displays the first IPv6 destination address that the test is to use for traffic to the DUT. You can use one address for all traffic going to the DUT, or you can use a range of addresses by clicking the Increment DUT IP Address field. 2. To configure First Port Source Address or First Port Gateway/DUT Address, click the appropriate Encode button. IxAutomate displays the IPv6 Address window. On this window, you select the IPv6 Prefix Type, and then configure the address and related parameters. The parameters displayed depend on the Prefix Type you select (Figure 3-32 on page 3-34 through Figure 3-35 on page 3-36). The Prefix Types you can select are: User-Defined, which allows you to configure all bits of the IPv6 address. Global Unicast, which is globally routable and reachable on the IPv6 portion of the Internet. Link Local Unicast, used for communication between hosts on the same link. Site Local, used for communication between nodes at the same site. 3. Select the IPv6 Prefix Type you want to use, then configure the parameters according to the corresponding table (Table 3-8 on page 3-34 through Table 3-11 on page 3-36). 4. Increment Field displays the field in the address that IxAutomate increments to create additional addresses. Select the address field that you want to increment. 5. If you want to use a range of destination addresses for traffic to the DUT, check the Increment DUT IP Address field. IxAutomate increments the First Port DUT Address to create additional destination addresses. If you do not check this box, IxAutomate uses the First Port DUT Address as the destination address for all traffic to the DUT.
3-33
Figure 3-32. User-Defined IPv6 Address Table 3-8. Parameter User Defined User Defined IPv6 Address Parameters Description Enter the complete IPv6 address.
Figure 3-33. Global Unicast IPv6 Address Window Table 3-9. Parameter Top-Level Aggregation ID Global Unicast IPv6 Address Parameters Description Enter the Top-Level Aggregation (TLA) ID. TLA IDs are assigned by IANA for Sub-TLA allocation. TLA IDs typically identify a high-level ISP. Reserved This field is reserved for future use to allow an increase in either the TLA ID or the NLA ID fields. It is normally set to 0 (zero). Enter the Next-Level Aggregation (NLA) ID. NLA IDs typically identify mid-level ISPs.
Next-Level Aggregation ID
3-34
Global Unicast IPv6 Address Parameters (Continued) Description Enter the Site-Level Aggregation (SLA) ID. SLA IDs identify the end-user site. The address prefix for end-user sites is usually supplied by the ISP that provides their IPv6 service.
Site-Level Aggregation ID
Interface ID
Enter the Interface ID. The Interface ID is usually generated from the interface LAN address. For example, for an Ethernet interface, the Interface ID is created by taking the first three bytes of the Ethernet MAC address, followed by FFFE, followed by the last three bytes of the Ethernet MAC address, and then performing an exclusive-or function of the result with 0200:0000:0000:0000. Because Ethernet addresses are globally unique, this generates a unique IPv6 address.
Figure 3-34. Link Local Unicast IPv6 Address Window Table 3-10. Parameter Interface ID Link Local IPv6 Address Parameters Description Enter the Interface ID. The Interface ID is usually generated from the interface LAN address. For example, for an Ethernet interface, the Interface ID is created by taking the first three bytes of the Ethernet MAC address, followed by FFFE, followed by the last three bytes of the Ethernet MAC address, and then performing an exclusiveor function of the result with 0200:0000:0000:0000. Because Ethernet addresses are globally unique, this generates a unique IPv6 address.
3-35
Figure 3-35. Site Local Unicast IPv6 Address Window Table 3-11. Parameter Interface ID Site Local IPv6 Address Parameters by Prefix Type Description Enter the Interface ID. The Interface ID is usually generated from the interface LAN address. For example, for an Ethernet interface, the Interface ID is created by taking the first three bytes of the Ethernet MAC address, followed by FFFE, followed by the last three bytes of the Ethernet MAC address, and then performing an exclusiveor function of the result with 0200:0000:0000:0000. Because Ethernet addresses are globally unique, this generates a unique IPv6 address. Enter the Subnet ID.
Subnet ID
Configuring IPX Addresses
If you are going to test a DUT using IPX traffic, you must do the following: Assign IPX socket numbers to the Ixia ports Assign IPX network addresses to the DUT ports
At the beginning of the each test, IxAutomate sends RIPX Request frames to the DUT ports. The DUT responds with a message containing the network and node address of each of its ports. IxAutomate uses these addresses to build IPX frames for the test. Figure 3-36 on page 3-37 shows an example of IPX addresses on a DUT and Ixia chassis.
3-36
Ixia card DUT Node: E0 00 00 01 00 00 Network: 01 02 03 04 Port 1 Node: E0 00 00 01 00 00 Network: 01 02 03 04
RIPX request RIPX response
Port 1
Port 2
Node: E0 00 00 01 01 00 Network: 02 02 03 04 RIPX request RIPX response Node: E0 00 00 01 02 00 Network: 03 02 03 04 RIPX request RIPX response Node: E0 00 00 01 03 00 Network: 04 02 03 04 RIPX request RIPX response
Node: E0 00 00 01 01 00 Network: 02 02 03 04 Node: E0 00 00 01 02 00 Network: 03 02 03 04
Port 2
Port 3
Port 3
Node: E0 00 00 01 03 00 Network: 04 02 03 04
Port 4
Port 4
Figure 3-36. IPX Address Assignment on Ixia and DUT Ports
How to Assign IPX Socket Numbers to Ports

The method you use for assigning IPX socket numbers to ports depends on the type of traffic map you selected: If you selected an Automatic traffic map, IxAutomate automatically assigns IPX socket numbers to ports. See Assigning IPX Socket Numbers Automatically on page 3-37. If you selected a Manual traffic map, you must assign IPX socket numbers manually. See Assigning IPX Socket Numbers Manually on page 3-38.
Assigning IPX Socket Numbers Automatically If you selected an Automatic traffic map, you provide the first IPX socket number, and IxAutomate applies it to the first port. For the next port, IxAutomate increments the first IPX socket number and applies the incremented value to the next port. The process repeats for each additional port, using the previous ports socket number as a base.
3-37
Port Names: Click this button if you want to name the ports. See Assigning Names to Ports on page 3-40.
Socket Address of First Port: Specify the first IPX socket number IxAutomate assigns to the first Ixia port. Figure 3-37. IPX Socket Number Assignment, Automatic Mode
Assigning IPX Socket Numbers Manually If you selected a Manual traffic map, you must specify the port IPX socket numbers manually. To assign IPX socket numbers manually: In the Frame Data area of the Traffic Setup window, click the Per Port Settings button.
Per Port Settings: Click this button to configure port IPX socket numbers. Figure 3-38. IPX Socket Number Assignment, Manual Mode
IxAutomate opens the Per Port Settings window (Figure 3-39 on page 3-39). You can use the Explorer-style tree shown in Figure 3-39 on page 3-39 or you can use a tabular-formatted window. To use the tabular format, click the Table Format button.
3-38
2. (Optional) Enter a name for the port.
3. Specify the IPX socket number you want to assign to the port.
To assign an IPX socket number to a port: 1. Select a port from the list.
5. Click OK to apply the socket numbers to the ports. Figure 3-39. IPX Per Port Settings Window
Click Table Format if you want to use a tabular-formatted window to apply IP addresses.
1. Select a port from the list. 2. If you want to assign a name to the port, enter a name in the Port Name field. Enter unique names for each port. 3. In the Source IPX Socket field, specify the socket number you want to assign to the port. 4. Repeat Step 1 through Step 3 for all the ports to which you need to assign socket numbers. 5. When you have finished, click OK to apply the socket numbers to the ports and to close the window.
3-39
Using the Table Format Window Figure 3-40 shows the Table Format window.
Name: (Optional) Enter a name for the port. IPX Address: Specify the IPX address you want to assign to the port.
Ports are identified by: CHASSIS, CARD, PORT.
OK: Closes window. Figure 3-40. Table Format Dialog for IPX
Assigning Names to Ports
You can assign names to ports to help organize your testing. 1. In the Frame Data area of the Traffic Setup window (Figure 3-22 on page 321), click the Port Names button. IxAutomate opens the Port Names window. You can use the Explorer-style tree shown in Figure 3-41 on page 3-41 or you can use a tabular-formatted window. To use the tabular format, click the Table Format button. Figure 343 on page 3-42 shows the tabular-formatted window.
3-40
Enter a name.
To name a port: Select the port.
Click OK. Figure 3-41. Port Protocol Configuration Window
2. Select a port. 3. Type the name that you want to assign in the Port Name field. The name should be unique; otherwise it is not validated. You may find it helpful to use a name that either: identifies the device the port is connected to (for example, Router_1), or describes how you are using the port (for example, Input_1). 4. If you are naming more than one port, repeat steps 2 and 3 5. When you have finished naming ports, click OK. You can see the port names display in the Port Setup window (Figure 3-42 on page 3-42).
3-41
Figure 3-42. Port Names Displayed in Port Setup Window
List of ports identified according to CHASSIS, CARD,

PORT
Enter names in the Name field.
Click OK to close the window. Figure 3-43. Port Name Window, Table Format
Setting the VLAN Parameters
IxAutomate uses two different methods to assign VLAN IDs: the QoS tests set the VLAN ID based on the destination port (the VLAN parameters are described in Chapter 11, Quality of Service (QoS) Test Suite), while all the other tests set the VLAN ID according to the transmit port.
3-42
VLAN Parameters (Excepting the QoS Tests)
Figure 3-44. VLAN Parameters - All the Tests, Except QoS Tests
Table 3-12 lists the VLAN parameters available in the IxAutomate (Frame Data section) for all the tests, except for QoS tests.
Table 3-12. Parameter Enable 802.1q Tag Adjust for Tag First Vlan ID VLAN Parameters Description Description Applies a VLAN tag suitable for a VLAN based the 802.1Q standard. If you check this box, the test compensates for a DUT that strips VLAN tags. The first VLAN tag to be assigned. For more information, see How IxAutomate Assigns VLAN IDs on page 3-43. If you check this box, the test increments, on a per-port basis, the VLAN tag it assigns to traffic from each port in the test. If you do not check this box, traffic from every port has the same VLAN ID.
Increment Vlan ID
How IxAutomate Assigns VLAN IDs
The following sections show how VLAN IDs are assigned in a four-port test using every combination of traffic map and transmit direction used in IxAutomate tests.
One-to-one
First VLAN ID: 10 From port: 1,1,1 To port: 1,1,4
Unidirectional For a test with a one-to-one unidirectional traffic map, IxAutomate assigns VLAN IDs as follows, starting with the lowest-numbered port:
VLAN ID contained in packet stream Stream 1,1,1 ----> 1,1,2 1,1,3 ----> 1,1,4 non-QoS Tests 10 11 QoS Tests 10 11
3-43
Bidirectional For a test with a one-to-one bidirectional traffic map, IxAutomate assigns VLAN IDs as follows, starting with the lowest-numbered port:
VLAN ID contained in packet stream Stream 1,1,1 ----> 1,1,2 1,1,2 ----> 1,1,1 1,1,3 ----> 1,1,4 1,1,4 ----> 1,1,3 non-QoS Tests 10 11 12 13 QoS Tests 11 10 13 12
One-to-Many
First VLAN ID: 10 From port: 1,1,1 To port: 1,1,4 Tx port: 1,1,4
Unidirectional For a test with a one-to-many unidirectional traffic map, IxAutomate assigns VLAN IDs as follows, starting with the lowest-numbered port:
VLAN ID contained in packet stream Stream 1,1,4 ----> 1,1,1 1,1,4 ----> 1,1,2 1,1,4 ----> 1,1,3 non-QoS Tests 10 10 10 QoS Tests 10 11 12
Bidirectional No test automatically creates a bidirectional one-to-many traffic map. However, if you create a manual map, you can create bidirectional traffic on one of the port pairs. For such a map, IxAutomate assigns VLAN IDs as follows, starting with the lowest-numbered port:
VLAN ID contained in packet stream Stream 1,1,4 ----> 1,1,1 1,1,4 ----> 1,1,2 non-QoS Tests 10 10 QoS Tests 10 11
3-44
1,1,4 ----> 1,1,3 1,1,1 ----> 1,1,4
10 11
12 13
Many-to-One
First VLAN ID: 10 From port: 1,1,1 To port: 1,1,4 Rx port: 1,1,4
Unidirectional For a test with a many-to-one unidirectional traffic map, IxAutomate assigns VLAN IDs as follows, starting with the lowest-numbered port:
VLAN ID contained in packet stream Stream 1,1,1 ----> 1,1,4 1,1,2 ----> 1,1,4 1,1,3 ----> 1,1,4 non-QoS Tests 10 11 12 QoS Tests 10 10 10
Bidirectional No test automatically creates a bidirectional many-to-one traffic map. However, if you create a manual map, you can create bidirectional traffic on one of the port pairs. For such a map, IxAutomate assigns VLAN IDs as follows, starting with the lowest-numbered port.
VLAN ID contained in packet stream Stream 1,1,1 ----> 1,1,4 1,1,2 ----> 1,1,4 1,1,3 ----> 1,1,4 1,1,4 ----> 1,1,1 non-QoS Tests 10 11 12 13 QoS Tests 10 10 10 11
Step 6: Choosing Frame Sizes
You can use the Traffic Setup window to set the frame sizes that you want to use in your test. When you run a test, each iteration or trial displays the results for each frame size. IxAutomate includes four modes for selecting frame sizes: Standard mode uses a list of frame sizes defined by RFC 2544.
3-45
Automatic mode uses a range of frame sizes which you define and increments them by a value which you also select. Manual mode allows you to define your own frame sizes. Imix (Internet Mix) mode transmits a variety of frames sizes simultaneously, enabling you to duplicate the mixture of different frames sizes typically found on the Internet.
Figure 3-45 shows the four Frame Size windows.
Figure 3-45. Frame Size Modes
How do I decide which frame sizes to use?

Which frame sizes to use depends to great degree on the device or protocol you are testing. However, as a rule, you should use frame sizes that include the maximum and minimum supported sizes for the protocol or device you are testing, and enough sizes in between to accurately characterize the DUTs performance. For example, to test an Ethernet device, you could use the following frame sizes: 64, 128, 256, 512, 1024, 1280, 1518 These sizes include the maximum and minimum frame sizes the Ethernet standard allows and a selection of sizes in between that yields a finer granularity for the smaller frame sizes and higher frame rates.
3-46
For some media types, you can gauge a DUTs per-frame processing overhead by specifying an unrealistically small frame size (one too small to include much or any data payload).
Standard Mode
In Standard mode, IxAutomate displays a list of frame sizes based on the list specified in RFC 2544. You can enable or disable each frame size by clicking on the check boxes.
Frame Size list: Check boxes to enable or disable frame sizes.
Figure 3-46. Frame Size, Standard Mode
Automatic Mode
In Automatic mode, you specify a range of frame sizes and a value to increment frames size by to go from smallest to largest. When IxAutomate begins the test, it sends frames at the smallest size you specified, then adds the Increment value to the frame size and repeats until it has run the test up to the largest frame size. You can specify frame sizes from 12 to 65535 bytes. If adding Increment the value to the previous frame size causes the next frame size to exceed the value for End Size, IxAutomate does not send those frames.
Start Size: Specify the smallest frame size to be used. Increment: Specify the number of bytes by which IxAutomate is to increase the frame size. Figure 3-47. Frame Size, Automatic Mode
End Size: Specify the largest frame size to be used.
Manual Mode
In Manual mode, you can specify a list of fixed frame sizes and IxAutomate runs the test using those frame sizes. You can specify frame sizes from 12 to 65535 bytes.
3-47
If you specify a frame that is smaller than the protocols smallest supported frame size, IxAutomate displays it in orange. If you specify a frame that is larger than the protocols largest supported frame size, IxAutomate displays it in red. In addition to observing the protocols minimum and maximum frame sizes, you should also refer to the Ixia Hardware Guide or the relevant data sheet to determine the minimum and maximum frame sizes supported by the load modules you are using.
Frame Size list: Specify the frame sizes to be used. You can specify sizes from 12 bytes to 65535 bytes. Undersize frames display in orange. Oversize frames display in red. Figure 3-48. Frame Size, Manual Mode
Imix Mode
Imix (Internet Mix) mode transmits a variety of frames sizes simultaneously, enabling you to duplicate the mixture of different frames sizes typically found on the Internet.
It allows you to add a frame to the list. See Adding an Imix Frame on page 3-48.
List of frame sizes, protocols, bandwidths (BW (%) and precedences.
It allows you to change the parameters for the selected frame. It allows you to remove a frame from the list. Select it, then click Delete.
It allows you to configure the protocol parameters from the protocol table. Figure 3-49. Frame Size, Imix Mode
Adding an Imix Frame To add an Imix frame: 1. Click the Add button to add a new Imix frame. 2. The Add Packet Parameters window opens, as shown in Figure 3-50 on page 3-49.
3-48
3. Fill in the available fields, then click Apply.
Figure 3-50. Imix Mode - Adding a Frame
Imix Frame Size Parameters Each Imix frame has a size, protocol, bandwidth, and precedence assigned to it. The bandwidth determines the distribution of the frame sizes within the total frames transmitted. The sum of all the bandwidths must be 100%. For example, if you create the following frame sizes and assign them equal bandwidths,
Size 64 128 256 512 1024 Bandwidth (%) 20 20 20 20 20 Protocol UDP TCP FTP HTTP DNS TOS IP Precedence Enabled Enabled Enabled Enabled Enabled
the test transmits equal numbers of each frame size. If you change one or more of the bandwidths, the test adjusts the numbers of each frame size to match the bandwidths; as a result, there are more higher-bandwidth frames and fewer lower-bandwidth frames. The total number of frames does not change. For example, if you change the bandwidths as follows,
Size 64 128 256 Bandwidth (%) 10 20 40 Protocol UDP TCP FTP TOS IP Precedence Enabled Enabled Enabled
3-49
Size 512 1024
Bandwidth (%) 20 10
Protocol HTTP DNS
TOS IP Precedence Enabled Enabled
the test transmits different numbers of each frame size: the 256 frame size is sent four times more than the 64 or 1024 frame sizes and twice more than the 128 and 512 frame sizes. The total number of sent frames does not change as compared to the first example. Table 3-13 describes the Imix frame size parameters.
Table 3-13. Parameter Size Protocol Bandwidth Imix Frame Size Parameters Description Enter a frame size to use in the test. You can enter any value supported by the port. Choose a protocol from the available drop-down list for the selected frame. Enter a bandwidth, as a percentage, for the currently selected frame size. Bandwidth is defined as how much information can be carried within a given time period (usually a second) over a communication link. The total bandwidths of all frames must be 100%. To create a stream that fills the remaining bandwidth, you have two possibilities: Write a large value (for example, 100) and then click in another field. This field is automatically updated to hold the largest correct value, resulting in 100% bandwidth usage. Use the Up arrow button until the fields value does not increase anymore. TOS Octet Type The Type of Service (ToS) field is contained in the IPv4 header for the Imix packets. You can choose between IP Precedence and DSCP. Depending on this setting, the IP Precedence or the DSCP parameter fields are available to be set. As IP Precedence settings, you can choose for the Precedence parameter one of the defined integer values in the 0-7 range as representing the level of precedence. As DSCP (Differentiated Service Code Point) settings, you can choose for the Mode parameter one of the defined modes available in the drop-down list.
IP Precedence DSCP Settings Mode
3-50
Step 7: Setting Up the Test Run Parameters
Once you have set up your ports and defined your traffic settings, your next step is to configure the Test Setup.
For Detailed Test Setup Information

The setup required for any given test is dependent upon the specific type of test that you are running. Refer to the appropriate chapter in this manual for details about the specific test setup parameters and options.
Iterations, Trials, and Test Duration

Many IxAutomate tests use parameter values in combination with each other. As these tests run, they make multiple passes, changing the value of the same parameter each time. When they have completed one pass for each value of that parameter, they change some other parameter, and then make another set of passes, again changing the original parameter each time. Most often, tests in IxAutomate test some condition or attributes behavior under varying frame sizes. For example, for a simple frame rate test, IxAutomate may set the frame rate at an initial rate, then test that rate using progressively larger (or smaller) frame sizes. After it has tested each frame size at the initial rate, it may change the frame rate, and re-test the same series of frame sizes in the same sequence. Iterations and Trials In IxAutomate, test passes are divided into iterations and trials: An iteration is the basic unit of a test sequence. For each iteration, IxAutomate changes one parameter value while holding all the others fixed. A trial consists of a repetition of all the iterations. For each trial, IxAutomate changes a parameter value other than the one changed in the iterations, and then runs through all the iterations again. A test typically includes a number of trials.
The result is a pair of parameters tested in every combination of values with each other. Many IxAutomate tests include the capability of selecting the frame sizes used in the test. Typically, for each frame size you select, the test runs a number of trials, and for each trial, a number of iterations (Figure 3-51 on page 3-52).
3-51
Iteration 1 Iteration 2 Iteration 3 Trial 1
Iteration n Frame Size 1 Iteration 1 Iteration 2 Iteration 3 Trial n
Iteration n Iteration 1 Iteration 2 Iteration 3 Trial 1 Iteration n Frame Size n Iteration 1 Iteration 2 Iteration 3 Trial n Iteration n
Figure 3-51. Trials and Iterations
Duration Many tests Run parameters include Duration, which allows you to configure how long a test is to run. A test uses the values for hours, minutes, and seconds to calculate the number of frames that need to be transmitted.
Figure 3-52. Duration Parameter
Effect of Trial Duration on Level 2 Switches If your test configuration includes a Level 2 switch, ensure that no trial exceeds the switchs forwarding table timeout interval. If the trial duration exceeds the timeout interval, you may see one or more MAC addresses suddenly disappear from the test window or the switch flooding the network with packets. IxAutomate uses a static Source Address (SA) and incrementing Destination Addresses (DAs) to create many test configurations. Because IxAutomate does not send Learn frames during a trial and the DAs generate no traffic, a switch
3-52
may drop the DAs from its forwarding table if the trial duration exceeds its forwarding tables timeout interval. Many Level 2 switches forwarding tables are set to timeout addresses after approximately 20 minutes. Some switches allow you to configure this interval; others do not. You can prevent this using the following methods: Configure a trial duration that does not exceed the switch forwarding tables timeout interval. If your switch allows you to configure its forwarding table timeout interval, use its management software to increase the interval.
Step 8: Configuring the IxAutomate Test Setup Options
This section describes the test setup options that enable you to customize your IxAutomate test environment. Three different tabs are available: Basic Test Options; For further information, see Configuring the IxAutomate Basic Test Options on page 3-53. Advanced Test Options; For further information, see Configuring the IxAutomate Advanced Test Options on page 3-56. Custom User Code; For further information, see Insert Custom Code on page 3-56.
Configuring the IxAutomate Basic Test Options

The Basic Test Options tab (Figure 3-53 on page 3-54) has the following three panes to describe and modify the basic setup of a test: Test Information Pane Output Settings Pane Port Ownership Pane
To retain the default settings that IxAutomate provides, select Defaults from the Settings menu.
3-53
Figure 3-53. Basic Test Options Tab
Test Information Pane The Test Information pane of the Test Setup Options window contains fields for documenting the device to test. IxAutomate includes these fields to help you manage your testing. All fields are optional, and you can enter any information you like. You can use any characters except quotation () mark, dollar ($) sign, and comma (,) sign. The fields display in the Results file for each test and in the run table available in the Data Miner window. Output Settings Pane The options available in the Output Settings pane are described in Table 3-14.
3-54
Table 3-14. Options
Output Settings Pane: Options Available Description Select this option to create a backup of the <testName.results> file. NOTE: When you run a test, a result summary in the form of a <testName.results> file is created. When you run the test again the <testName.results> file is replaced with results from the latest test if the Backup results file option is not selected. However, if you select the Backup results file option, a backup of the <testName.results> file generated during the earlier test is created. This backup file is saved at the same location but, a randomly generated suffix is appended to the file name to distinguish it from the latest <testName.results> file.
Backup results file
Flat directory structure Select this option to create all the test run files in the same location. When you select this option the files generated for each test run have unique names, so the files from the latest test run do not replace the files generated during a previous test run. For more information, see Default Directories for CSV Files on page 3-74. Unique result file name Select this option to save the generated files with unique names. The name of the results files is made up of two parts the current name of the result file and a key that makes the result file unique in the results directory. The key is created by merging Test Category, Test Name, Configuration Name, and Run number. For example, result.csv file name for the RFC 2544 Back to Back test is: results_RFC 2544_Back to Back_test_1_Run0001.csv User defined result directory Enter the location where you want to save the generated files.
Port Ownership Pane The Port Ownership pane of the Test Setup Options window allows multiple users to run scripts on the same chassis, but in separate, reserved sets of ports. You can log on with unique user IDs and take ownership of ports on one or more chassis. Enter a name in the Login field and make sure you enter a name that is different from any other users sharing the chassis.
3-55
Configuring the IxAutomate Advanced Test Options

You can use the Advanced Test Options tab (Figure 3-54) from the Test Setup Options window to modify aspects of IxAutomates behavior. The advanced parameters for any given test are dependent on the specific type of test that you are running. For more information about the list of available parameters, refer to Chapter 4, Advanced Parameters.
Figure 3-54. Advanced Test Options Tab
Insert Custom Code

IxAutomates Custom User Code tab from the Test Setup Options window enables you to insert Tcl commands into a test. If you add custom code, IxAutomate executes the commands immediately before it applies the test configuration to the Ixia hardware. For more information about Custom User Code, refer to Chapter 4, Inserting Custom User Code.
Step 9: Setting Up the StatViewer Statistics
The StatViewer software component is used to display the test graphics and statistics. StatViewer provides default views for each test within IxAutomate application. As an option, you can select from the predefined list of views and associate them with a test. You can also create your own views for a test by indicating the statistics to display and defining properties such as background color and line style.
3-56
The available statistics for IxAutomate are: Real-Time Aggregated Stats Count Real-Time-Per-Port Stats Count
After setting the desired statistics, use the Apply button from the Statistics setup main window to include the settings in the test results. For more information about the available test results, refer to Test Results on page 3-69. For information about StatViewer, see the StatViewer User Guide. It can be accessed from the Help menu.
Configuring the Test Statistics and Graphics Options

The Test Statistics options are: the Polling Interval indicates how often the statistics group is collected, in seconds (s), from the Ixia port. CSV Files Path enables you to specify the destination folder where the CSV files are written. You can see the results in the viewer associated with CSV files. Enable CSV logging for all views if checked, the StatViewer enables CSV logging for the particular view. Enable Data Store for all views it checked, StatViewer writes the statistical values in binary format for all test results in a view. The test result is converted into a binary array and written to a file.
When finishing the settings, use the Apply button to include the settings in the test results. For more information about the available test results, refer to Test Results on page 3-69. The Graphical Options allows you to set the color for the charts and grids: Chart Color Palette for all views Grid Color Palette for all views When finishing the settings, use the Apply button to include the settings in the test results. For more information about the available test results, refer to Test Results on page 3-69.
Step 10: Setting Up the Device Under Test (DUT) Parameters
The DUT Setup window contains two tabs: DUT Parameters Tab on page 3-58 DUT Polling Tab on page 3-60
3-57
DUT Parameters Tab

The DUT Parameters tab (Figure 3-55) allows you to enter script commands and their arguments in order to configure the DUT. You can set the commands to be executed before or after each test, trial, frame size, or iteration. Two check boxes are available for each of the command lines: Run in Background, which allows you to run the scripts in the background. Stop at Cleanup, which allows you to stop the running scripts at cleanup.
You can choose to include the DUT configurations in the reports by enabling the Include DUT Configuration in Reports check box.
Clear All: If you click this button, the content of the DUT Setup fields is deleted. Enable DUT Configuration: If you enable this check-box, the parameters can be set.
Global Arguments: This list of arguments is applied to all scripts. The entire list of arguments for a script is obtained by concatenating the global arguments list with the arguments specific to the script. Figure 3-55. DUT Parameters Tab
The Command fields can have the following form: name of the program executing the script (the most frequently used program is expect) followed by the path of the script to be executed.
3-58
An sample script that can be entered in the Test Setup Command field is shown in the Figure 3-56 on page 3-59.
Figure 3-56. Script Configuration Example
Figure 3-57 shows a fragment from the show running configuration with the commands applied by the script to the DUT.
Figure 3-57. Show Running Configuration Fragment
After the test completes, you can clean the configuration on the DUT. Figure 358 on page 3-60 shows an example of a clean script that can be entered in the Test Cleanup Command field.
3-59
Figure 3-58. Clean Configuration Script
DUT Polling Tab

The DUT Polling tab (Figure 3-59) offers polling capabilities to the DUT. It allows you to enter a polling script and run it on the DUT while the test is running.
Figure 3-59. DUT Polling Tab
To run a polling script, the following data is required: the Initial DUT Configuration Script enter the path for the DUT configuration script that runs once to set up the DUT parameters and leave the connection open for the polling script. Figure 3-60 on page 3-61 shows an example of initial DUT configuration script and Figure 3-61 on page 3-61 shows an example of expect script to store data retrieved from the DUT in the file you have created. the Polling Script Path enter the path for the polling script that sends commands to the DUT and logs the response. Figure 3-62 on page 3-62 shows an example of polling script and Figure 3-63 on page 3-62 shows an example of expect script to append data retrieved from the DUT to the previously created file. the Polling Interval enter the period of time for the polling interval, expressed in seconds (s).
3-60
Figure 3-60. Initial DUT Configuration Script Example
Figure 3-61. Expect Script Example
3-61
Figure 3-62. Polling Script Example
Figure 3-63. Expect Script Example
Both scripts are written by you and are completely under your control. The scripts perform the DUT logon routines, as well as retrieving data after the commands are sent. If you choose to include the polling results in the reports, enable the Include Polling Results in Reports check box. The Report File (script output) field allows you to specify the path for the output file. The output file is the file created by your scripts and it is included in the polling section of the report if the provided path is valid.
Step 11: Running a Test
After setting up the test parameters and the statistics, you are ready to run the test. Start the test by clicking the Start button (or pressing the F5 key), or by selecting the Start option from the Run menu.
3-62
You can run a test at a scheduled time and date. To schedule different test configurations to run automatically at a specified time and date, use the Batch Scheduler feature. For more information, refer to Scheduling Test Configurations on page 3-63. For a description of the test output that you can receive from a test run, see Obtaining Test Output on page 3-69.
Scheduling Test Configurations

Configuration Files area
The Batch Scheduler feature allows you to schedule different configurations to run automatically at a specified time and date.
Creating a New Batch File

To create a new batch: 1. Right-click Batches/Run View in the Batch Files left pane and check the New Batch option. The New Batch window opens (Figure 3-64). As an alternative, choose the New option from the File menu. 2. A default name is available for the new batch; you can also enter a different name for the batch.
Figure 3-64. New Batch Dialog Window
3. Click OK. IxAutomate creates a new batch file using the name you specified and adds it in the Batch Files pane, as shown in Figure 3-65.
Figure 3-65. Batch Scheduler Pane
Configuring a Batch File

By creating a new batch, IxAutomate adds it in the Batch Files pane and displays it in the right pane the Batch Editor window.
3-63
The Batch Editor window (Figure 3-66) provides three areas for the description and modification of the basic setup of a batch: 1. The Configuration Files area, which contains the list of the test configurations you selected for the batch. Each line shows information about the test suite and the name of the configuration file to run. It allows you to: add a test configuration in the batch, by using the Add button. The Select Configuration Files dialog opens (Figure 3-67 on page 3-66) and you can choose the test configurations that you want from the list. For each batch, you can add one or more test configurations.
Note: You can add more test configurations at a time, by selecting them in the list using the Ctrl, Shift or Ctrl+A keys.
delete a selected test configuration from the batch by using the Delete button arrange the test configurations in the batch, by using the Up and Down buttons generate PDF formatted-reports for all tests if the Generate PDF reports for all tests check box is checked 2. The Scheduler area, which allows you to choose when to run a batch: when the Batch Scheduler starts by enabling the When Batch Scheduler Starts check box every day, if you choose the Day option for the Run Every parameter field. Then you must select the time when the test is to start running. every week, if you choose the Week option for the Run Every parameter field. Then you must select at least one day of the week, as well as the time when the test is to start running. every month, if you choose the Month option for the Run Every parameter field. Then, you must select at least one month, the day of the month, as well as the time when the test is to start running. 3. The Test Information area, which allows you to specify custom information for either a new or an existing set of tests, and also a login name for ports ownership: Product Name Version Number Serial Number User Name Comments Login name These fields are used in the batch run for all the configuration files included, instead of the Test Information values defined in each of the configuration files.
3-64
Note: Batch Scheduler always creates a temporary copy of the configuration file that must be executed. If test information or port ownership information is defined in the batch configuration file, the batch scheduler overwrites in the temporary configuration file the values from the original configuration file with the ones from the batch configuration file. When the test configuration files that were included in the batch are separately run (not in batch scheduler), they keep the values from the original configuration file.
Test Information and Port Ownership area
Scheduler area
Figure 3-66. Batch Scheduler Batch Editor Window
3-65
Figure 3-67. Batch Scheduler - Select Configuration Files Dialog
After setting the batch, you can save the newly-created batch file by selecting the Save or Save as option from the File menu; the default path for saving the batches files is:
<installation path>\IxAutomate\Configs\BatchFiles
Otherwise, click the Exit option from the same menu. If you want to see the batches list, click Batches/Run View in the left pane; the Batch List window displays in the right pane (Figure 3-68). Each row in the table consists of one batch. The information available for each batch is: batch name test suites to run time of the next run scheduled period scheduled time and day batch status
3-66
Figure 3-68. Batch Scheduler Batch List Window
Below the batch list, a message informs you about each batch from the list status.
Running a Batch File

After setting up the batch, click the Start button (or press the F5 key), or select the Start option from the Run menu. The test runs at the specified time and date.
Viewing the Test Log

While a test is running you can view the test log for that test (Figure 3-69). Click Log View, and then select a test from the list of current tests.
3-67
Figure 3-69. Batch Scheduler Test Run Log
Batch Results
The results for each batch run are stored in the default path: <installation path>\ IxAutomate\Results\BatchResults as CSV files. The results for each test run from the batch are saved in the default location for result folders (as if they were run from the GUI) and are also displayed in Data Miner. Each row in the CSV file contains the following information: the batch name, the test type, the configuration test name, the date and the time when the test starts running, the number of executed and passed trials, the duration of each trial, the product name, the version number, the serial number, and the user name. If the Generate PDF reports for all tests check box is enabled, IxAutomate creates a PDF report for each test run, in the corresponding results folder. For further
3-68
information please refer to Test Results on page 3-69. If the same test runs twice, for example, you have the results for each test running instance.
Step 12: Obtaining Test Output
As soon as you start running a test, IxAutomate opens the Logs window to show the progression of steps in the test script. Two tabs are available: the Test Run Log displays the main test run log that also contains brief information about the DUT configuration notification. DUT Setup Log displays the DUT configuration log that contains the complete command and the output for setup/cleanup commands.
In the left pane, the Loop Hierarchy pane is available to help you view the test execution structure. Selecting one item from the loop hierarchy tree, for example, the prelude item for the Test Run Log tab, the real-time log lines displays. The trial loop items have different colors according to the trial status: red/green/black color for failed/passed/not available status. If IxAutomate cannot successfully run the test, it displays one or more messages in the Test Run Log tab, indicating the cause of the failure. Otherwise, in the Statistics window, the real-time statistics of the test are available. This section describes the options for obtaining and managing your test output: Test Results on page 3-69. Real-Time Graphs and Statistics on page 3-69. Accessing Prior Test Run Results on page 3-71. Accessing CSV Output on page 3-73.
Test Results
The content of the Logs tabs is available as text file and the values for the graphs displayed in the Statistics window are available as CSV files (Real-Time files). The results for each test run are stored in the default location <installation path\ IxAutomate\Results directory or in a custom location as specified in the configuration file. For further details, please refer to Output Settings Pane on page 3-54. In IxAutomate, the results are shown in the Data Miner window, which opens when selecting the Data Miner button. You can access the test results at any time (see Accessing Prior Test Run Results on page 3-71).
Real-Time Graphs and Statistics
The Statistics window displays the real-time graphs and/or statistics (Statistics Main Window on page 3-70). IxAutomate provides two runtime statistics for the test output, as the test progresses through its iterations and trials: Real-Time Aggregated Stats Count Real-Time-Per-Port Stats Count
The StatViewer software component is used to display the test graphics and statistics. To configure how to display the results in the Statistics window, use the Tools | StatViewer menu.
3-69
For information about StatViewer, see the StatViewer User Guide. It can be accessed from the Help menu.
Figure 3-70. Statistics Main Window
Disabling Real-Time Graphs and Statistics

The real-time graphing in IxAutomate consumes a significant amount of memory (RAM) and CPU time. If you are running a very long test, or a test that includes a large number of ports, you may want to disable real-time graphing to improve IxAutomate performance. To disable real-time graphing: 1. Select Preferences. The Preferences window opens. 2. Click the StatViewer option from the left pane, then clear the Enable Stat Viewer check box.
3-70
Generating the Real-Time Graph Data from a Command Line

The real-time graphs use data from a comma-separated values (CSV) file named RealTime.csv. RealTime.csv is created during a test to store the data for the graphs. If you run your IxAutomate tests from a test script invoked from a command line, you can also generate the RealTime.csv file. To enable creation of the real-time graph data, include the following line in your test script:
testConf(enableRTSS) true
Accessing Prior Test Run Results
When you select the Data Miner button, IxAutomate displays (Figure 3-71 on page 3-72): The Data Miner pane on the left side of the window, containing the available test configurations for each test run and a filter test run parameter field; A run table that lists all the test runs that you have executed; A details pane, containing the logs file, CSV file reports, text report, the statistics and the graphical views for the test that you have selected in the run table.
3-71
Run Table: Displays the list with test runs for the selected test. If you select an item, the associated csv, log, and test reports are automatically loaded and available for viewing in the bottom page pane.
Details Pane: Displays the CSV reports, text report, and the log file for the selected test run. Figure 3-71. Data Miner Window
You can perform several actions on any of the test runs listed in the run table (Figure 3-72 on page 3-73). Use the following procedure to access a prior test run: 1. Select the Results View button from the View menu or from the Tool Bar, for any of your defined tests. 2. Select the desired test run from the run table (click anywhere in the row). 3. Right-click to display the floating actions menu (Figure 3-72 on page 3-73).
3-72
Explore Results Folder: Displays Delete Runs: the explore window containing the test results folder. In the browser you Deletes the test can see the path for the results folder. results file.
Generate Report (Wizard): Displays the generate report wizard, allowing you to select the report, the exported StatViewer image, and the report output location.
Reload Configuration: The test configuration used for that test result file is reloaded.
Re-Run Test: Re-runs the test and creates a new test results record.
Modify Report Options: Displays the Global Report Options wizard, allowing you to specify the cover page image and logo image, as well as the output options.
Manage Reports: Displays the manage report wizard, allowing you to set the reports you want to be generated for your test run.
Figure 3-72. Floating Actions Menu
Accessing CSV Output
When running a test, IxAutomate creates a set of CSV (comma-separated value) files containing the test results, depending on what you set in the Tools | Options Reports tab. Table 3-15 describes the CSV files that IxAutomate generates. The info.csv file always contains the same type of data, whereas the content of the other CSV files is test-dependent. The portMap.csv file contains the Traffic Map and the ports speed settings. (The data presented in these files reflects the data presented at the conclusion of a test in the Logs window and in the Statistics window.)
Table 3-15. CSV file info.csv List of Generated CSV Files File contents User name, DUT identification, comments, test duration, duration of each trial, number of trials, number of trials passed, date and time. Generated only for tests that perform a binary search. The file contains information describing the parameters used for each iteration attempted during a binary search. Summary of iterations, showing the best iteration value (based on the tolerance defined for the test). For example, if the frame loss tolerance is zero, then the best iteration would be that which yields no loss. Results are shown per port.
Iterations.csv
results.csv
3-73
Table 3-15. CSV file
List of Generated CSV Files (Continued) File contents Statistical summaries of the results values (for example: sum, average, minimum, maximum). Results are averaged across all ports in the test. Not all tests generate the aggregate.csv file.Tests that use binary search generate this file, but most of the other tests do not.
AggregateResults.csv
PortMap.csv
Traffic setup settings on the transmitting and receiving Ixia ports and their speed. The speed is expressed in Mb/s and the number representing the port has the standard format of chassis.card.port. If the map is not one to one (that is, a port transmits to several ports), the information under TxPort and TxSpeed is not shown, as it would be redundant.
ReportBase.csv TheoreticalMaxRates. csv
The test configuration is saved in this report. All the test parameter settings are kept in this report. This report is available only for the RFC 2544 tests. It contains the list of theoretical maximum frame rates values for all traffic types.
You can load these CSV files into any standard spreadsheet program (or any application that reads CSV files) to analyze and graph the data.
Note: Because IxAutomate uses the generated CSV files to create the PDF report files, Ixia recommends that you leave the CSV files unaltered. When you load them into a spreadsheet program, be sure to save them in the native file format of the application program that you are using (XLS files for Excel, for example).
Default Directories for CSV Files

IxAutomate stores the generated CSV files in the following directories: In the Windows operating system, the default directory for CSV files is <installation path>\IxAutomate\Results. In the Linux and Unix operating systems, the default directory for CSV files is <IxAutomate directory>/Ixia/Results, where <IxAutomate directory> represents the path where IxAutomate is installed.
IxAutomate creates: individual subdirectories for the CSV output from each test run, this being a default setting
or all the test results are saved in the same directory, if the Flat directory structure option is checked in the Basic Test Options tab or if the Defaults option
3-74
is selected in the Settings menu. The results files are created directly in the Results directory and the files are named as follows: resultFiles_testSuite_testName_configName_Run[runNumber].extension For example for RFC 2544 Throughput test the result file is: results_RFC2544_Throughput_TestExample_Run001.csv For the last run, the result file does not have the Run[runNumber] appended to its name.
Optional Information in Report Files

The created report files can contain only the desired information. You can essentially pick results, iterations, aggregate results, or just port map settings. To choose which results to include in the generated report: Select Settings | Preferences to open the Preferences window. Click the Report option to enable the check boxes.
Note: For the tests that do not support some of the CSV files (for example, Iterations), the corresponding check box is disabled.
Generating Optional Pages in PDF Files from a Command Line

The report files use data from the comma-separated values (CSV) files. If you run your IxAutomate tests from a test script invoked from a command line, you can also generate optional pages in report files. To enable PDF files generation, set the following line in your test script to true:
testConf(generatePdfEnableRTSS) true
The optional pages are included in the following lines in your test script (the values are set to true by default, which means that the respective pages are shown in the PDF file):
testConf(displayResults) true testConf(displayAggResults) true testConf(displayIterations) true testConf(displayPortMap) true
For each test running instance, a new PDF file is created. If the file already exists, it is deleted and replaced with a new one. The new file is generated in the new conditions (the newly-selected values for what is to display).
3-75
3-76
Chapter 4:
Customizing the Test Environment
This section describes the more advanced features that enable you to customize your IxAutomate test environment. These features include the following: Configuring the IxAutomate Advanced Options on page 4-1. Advanced Parameters on page 4-7. Configuring a Chassis Timing Source on page 4-9. Inserting Custom User Code on page 4-10. Running a Test Outside IxAutomate on page 4-12.
Configuring the IxAutomate Advanced Options

You can use the Preferences window to modify aspects of IxAutomates behavior.
To configure IxAutomates options:

1. From the menu bar, choose Settings | Preferences. IxAutomate opens the Preferences window, which, in turn, has three windows, one for each of the three options: General, Report, and StatViewer. 2. Use the controls in each window to modify IxAutomate to suit your preferences. Refer to: Figure 4-1 on page 4-2 and Table 4-1 on page 4-2 for a description of the General controls. Figure 4-2 on page 4-3 and Table 4-2 on page 4-4 for a description of the Report controls. Figure 4-3 on page 4-4 and Table 4-3 on page 4-4 for a description of the StatViewer controls. 3. When you finish modifying IxAutomates options, click OK to make the changes take effect and close the window. To close the window and discard
4-1

any changes you made, click Cancel. To display the Help window, click Help.
Figure 4-1.
Options Window General Tab
Table 4-1 lists a description of the controls shown in figure Figure 4-1.
Table 4-1. Parameter Use off-chassis Hardware Manager Preferences Window - General Controls Description If you enable this box, the Hardware Manager component is not used from the chassis itself. It can be installed and run from a separate PC (if you do not choose localhost, or enter the host IP address). For more information, see Using the Off-Chassis Hardware Manager Option on page 4-5. Keep port names when loading another test If you check this box, IxAutomate retains the port names used in the previous test when you load a new test. If you do not check this box, IxAutomate discards the port names used in the previous test. Keep addresses and VLANs when loading another test If you check this box, IxAutomate retains the addresses and VLAN IDs used in the previous test when you load a new test. If the new test already contains configured addresses and VLANs, IxAutomate uses those addresses and VLANs instead. If you do not check this box, IxAutomate discards the IP/IPv6/IPX addresses and VLAN IDs used in the previous test. Log DUT Configuration If you enable this check box, DUT Configuration messages appear in the Log file.
4-2

Table 4-1. Parameter Enable Log
Preferences Window - General Controls (Continued) Description If you enable this check box, the log file displays in the Test Run Log tab. Otherwise, the log file is saved in the Results folder, but it is not printed in the Test Run Log tab. If you enable this check box, date and time of the logged events appear in the log file. If you enable this option, when you modify a test configuration and run it, the changes are automatically saved. Otherwise, a dialog is displayed asking you if you want to save the changes. If you select Yes the configuration is saved/overwritten in the current location of the configuration file. If you choose No, the test runs with the latest changes, but the changes are not saved in the current location of the configuration file. By default, this option is enabled. The option has no effect in case of reloading from Data Miner a different configuration from the previous one, unless you manually modify the reloaded configuration.
Log Timestamps Auto save on test run
Save current configuration on exit
If you check this box, IxAutomate saves your current choice of test and window layout. The next time you start IxAutomate, it reloads the same window layout and test.
Figure 4-2.
Options Window Display Tab
Table 4-2 lists a description of the controls shown in Figure 4-2.
4-3

Preferences Window - Report Controls Description
Toggle Results On/Off If you uncheck this box, IxAutomate generates only the Info.csv report. Display Aggregate Results Display Per Port Statistics Display Iterations Results Display Port Map Report Title Page Comments Graph Type for RFC 2544 If you check this box, IxAutomate generates optional pages in reports, containing the aggregate results. If you check this box, IxAutomate generates optional pages in reports, containing per-port statistics. If you check this box, IxAutomate generates optional pages in reports, containing the iterations results. If you check this box, IxAutomate generates optional pages in reports, containing the port map settings. The comments added in this check box appear on the first (cover) sheet of the generated reports. You can choose how to generate the graphs for RFC 2544 tests: Line Graph and/or Bar Graph.
Figure 4-3.
Preferences Window - StatViewer Controls
Table 4-3 lists a description of the controls shown in Figure 4-3.

Table 4-3. Parameter Enable Stat Viewer Preferences WIndow - StatViewer Controls Description If you check this box, the real-time graphs and statistics display during the test run in the Statistics window. You may want to disable this option in order to improve performance for long tests or tests including a large number of ports.
4-4

Using the Off-Chassis Hardware Manager Option

Hardware Manager is an IxOS component that manages the resources on an Ixia chassis. Applications like IxAutomate communicate with a chassis through Hardware Manager. Normally, Hardware Manager runs on the chassis itself. However, it can also be installed and run on a separate PC. This configuration is known as an Off-chassis Hardware Manager. Hardware Manager running on the chassis is known as an On-chassis Hardware Manager. The IxAutomate application supports Off-chassis Hardware Managers running on either the same host as the application or on a third host. Figure 4-4 on page 45 shows the Hardware Manager configurations available for IxAutomate.
Ixia chassis Ixia chassis NIC IxAutomate Windows client PC Windows PC IxAutomate chassis components Hardware Manager IxAutomate client
IxAutomate chassis components IxAutomate client Hardware Manager
IxAutomate chassis components IxAutomate client Hardware Manager
Figure 4-4.
Hardware Manager Configurations
To use an off-chassis Hardware Manager with IxAutomate: 1. Select Preferences from the IxAutomate Settings menu and then choose the General tab; 2. Enable the Use Off Chassis HWM option; 3. Enter the IP address of the host where the Hardware Manager component resides. It can be the localhost or any other host IP address. If you choose the localhost, and then connect to a chassis, the Hardware Manager running on the local IxAutomate client PC takes precedence over the Hardware Manager running on the chassis (if there is one) and takes
4-5

control of that chassis. Any other instance of IxAutomate (for example, GUI) that tries to access that chassis must also use a local Hardware Manager; otherwise, it cannot access the chassis. To stop using the off-chassis Hardware Manager, disable the Use Off Chassis HWM option.
4-6

Advanced Parameters
Advanced Parameters
IxAutomates Advanced Parameters give you increased control over aspects of a tests configuration that are otherwise set to typical default values. Table 4-4 describes the parameters encountered in all the tests. Configure the parameters that you want to change. The values that you select remain in effect for every subsequent test.
Table 4-4. Parameter Max. Connect Retries IP TTL Advanced Test Parameters Description Maximum number of attempts to connect to the chassis. If the test cannot establish a connection to the chassis within the allowed number of attempts, the test stops. IP Time-to-live field. The TTL field ensures that undeliverable datagram do not circulate endlessly in a network. Each time a router receives a datagram, it decrements the TTL field by one and then forwards the datagram. If decrementing this field drops its value to zero, the router discards the datagram. UDP source port number. Typically, if the datagram originates from a client, the source port number is an ephemeral port number; if the origin is a server, the port number is a well-known port number. UDP destination port number. Typically, if the datagram originates from a client, the destination port number is a well-known port number; if the origin is a server, the port number is an ephemeral port number. TCP source port number. TCP source port number usage follows the same general rules as UDP described above. TCP destination port number. TCP destination port number usage follows the same general rules as UDP described above. Delay between the time the test checks the link states and the start of transmission. Some DUT require additional time to prepare for transmission. Select this option to transmit additional traffic before the real traffic is transmitted to allow DUT to populate its forwarding table. The additional traffic is the same as the real traffic but it is not included in the results. This value is the interval of time, expressed in seconds, to wait for the GPS receiver until it locks onto the satellites in order to synchronize its date and time.
UDP Source Port
UDP Destination Port
TCP Source Port TCP Destination Port DUT Transmit Delay Enable Prime DUT
GPS Lock Timeout (s)
Link State Timeout Prime DUT Time (s) Saved Termination Option
Number of seconds that can elapse with no activity on the link before the test assumes that the link is down. Specify the duration for which the Prime DUT traffic is transmitted. Specifies the terminating text string appended to the end of a IxAutomate script.
4-7

Advanced Parameters
Advanced Test Parameters (Continued) Description If you select this option, instead of using the port and protocol configuration defined in IxAutomate, the test imports the configuration from IxServer (and created using IxExplorer) on the test chassis and uses it for the test session. This option is only supported on the following tests: All RFC 2544 tests All RFC 2889 tests excepting the Address Cache Size and Address Rate test All RFC 3918 tests ATSS All Mesh test ATSS Throughput NAT test ATSS Throughput test ATSS Traffic Tester IxGreen tests
Use IxServer Config:
Stream Frame Type Stream Pattern Type
Value of the Ethernet Length/Type (EtherType) field. The standard value for this field is x0800. The IEEE maintains the list of registered EtherType values. Determines how the test creates the data pattern used in the stream: incrByte: The data starts with a byte of 0x00, followed by 0x01, 0x02, , 0xFE, 0xFF, 0x00 to the end of the packet. New packets start again with a value of 0x00. incrWord: The data starts with a word of 0x0000, followed by 0x0001, 0x0002, , 0xFFFE, 0xFFFF, 0x0000 to the end of the packet. Data is transmitted most significant byte first. decrByte: The data starts with a byte of 0xFF, followed by 0xFE, 0xFD, etc., to the end of the packet. New packets start again with a value of 0xFF. decrWord: The data starts with a word of 0xFFFF, followed by 0xFFFE, 0xFFFD, etc., to the end of the packet. Data is transmitted with most significant byte first. patternTypeRandom: Random data values are supplied. repeat: Arbitrary data patterns are supplied and repeated. These patterns may be created, edited, retrieved from disk, and/or stored to disk. nonRepeat: Arbitrary data patterns are supplied but not repeated. These patterns may be created, edited, retrieved from disk, and/or stored to disk.
4-8

Configuring a Chassis Timing Source
Advanced Test Parameters (Continued) Description Pattern of bits transmitted. dataPatternRandom: Generates a random arrangement of bits. allOnes: Bit pattern consisting of 1s in all positions. allZeroes: Bit pattern consisting of 0s in all positions. userpattern: User-entered data pattern. xAAA x5555 x7777 xDDDD xF0F0 x0F0F xFF00FF00 x00FF00FF xFFFF0000 X0000FFFF x00010203 x00010002 xFFFEFDFC xFFFFFFFE
Stream Data Pattern
IP Protocol Percent Loss Format Remove Streams at Completion
Transport-layer protocol Specifies the number of digits displayed on either side of the decimal point for percent loss results. If you check this box, IxAutomate destroys the streams it created for the test when the test is finished. IxAutomate includes this option for users who use IxAutomate to run tests that create a large number of streams and then use IxExplorer examine the results. Large numbers of streams can cause the IxExplorer window to take a long time to refresh.
Stop Protocols and Transmission on Early Termination
If you check this box, stopping a test prematurely (using the Stop button) causes IxAutomate to stop the protocol emulation and data transmission services on the port. This option improves IxAutomates performance if you frequently stop and re-start tests for the same protocol.
Verify All ARP Replies (IP Multicast tests only) In an IP multicast test, this option verifies that the test receives ARP replies from all the addresses that have been ARPed. Most non-IP multicast tests only need to ensure that they receive one ARP reply. Because the multicast tests host multiple addresses on a port, this option ensures that all of the addresses send replies.
Configuring a Chassis Timing Source

Chassis timing can be derived from any of the following sources:
4-9

Inserting Custom User Code
Internally, deriving timing either independently from the chassis clock (if the chassis is the master chassis in a chain or not connected to another chassis), or from a Sync-In signal from the previous chassis in a chain. Through GPS, deriving timing from the chassis integral GPS receiver. GPS can provide very precise chassis synchronization. TDM synchronization between multiple chassis. This option helps to run multiple applications like IxN2X, IxNetwork, and IxLoad simultaneously on a single platform.
You can select the chassis timing source while you add the chassis, using the Add Chassis window (see Figure 3-8). You can also change it at any point of time. To change a chassis timing source do the following: 1. Navigate to the Add Chassis window. 2. Select the Timing Source from the list. You can select any of the following options: Internalto derive timing either independently if the chassis is the master chassis or not connected to another chassis, or from a sync-in signal from the previous chassis in a chain. This option is selected by default. GPSto derive timing from the chassis integral GPS receiver. TDMto synchronize the time between multiple chassis. 3. Click Apply.

IxAutomates Custom User Code window enables you to insert Tcl commands into a test. If you add custom code, IxAutomate executes the commands immediately before applies the test configuration to the Ixia hardware. Adding custom user code is a convenient way to change the hardware configuration temporarily without modifying the original test script.
To insert Custom User Code:

1. Select a test configuration and choose Options under the Test Setup option from the left pane. 2. In the Custom User Code window, enter the Tcl commands that you want the test to execute.
4-10

Figure 4-5.
Custom User Code Window
When you start the test, IxAutomate executes the commands that you entered immediately before it applies the configuration to the Ixia hardware.
4-11

Running a Test Outside IxAutomate

You can run a IxAutomate test without using the IxAutomate user interface. Combining this capability with a scheduler application allows you to run IxAutomate tests unattended. Although you can run a test without using the interface, you must use the interface to configure the test. This section covers the following topics: Windows on page 4-12. Unix/Linux on page 4-13.
Windows
To run a test outside IxAutomate, use the following procedure: 1. Start IxAutomate, and load the test you want to run. 2. Configure all the test parameters, then save the test and close IxAutomate. 3. To test the file, double-click the Wish Console icon to open a Wish Console window (Figure 4-6).
Figure 4-6.
wish Console Icon
The Wish Console (Figure 4-7) is a windowing shell for Wish, a simple program consisting of the Tcl command language, the Tk toolkit, and a main program that reads commands from standard input or from a file.
Figure 4-7.
wish Console
4. From the console window menu bar, select File | Source. 5. Locate the file you want to run, select it, then click Open. In a default Windows installation, IxAutomate files (multiple versions are supported) are stored in the following path:
C:\Program Files\Ixia\IxAutomate\<Version>
4-12

6. IxAutomate loads the test file you configured and runs the test. If the test runs as you expected, continue with the next section to configure the test to run unattended.
Unix/Linux
1. If you are using a graphical interface such as KDE or Gnome, open a Terminal window. 2. Change your path to the directory containing the ixwish shell. If you installed the Tcl Client (which installed the ixwish shell) using the default path, the path is:
/<Tcl install path>/bin/ixwish
3. Start the ixwish shell by typing:

./ixwish
When the ixwish shell starts, the shell prompt changes to a percent sign (%) and a wish window opens (Figure 4-8).
Figure 4-8.
Wish Window and Ixwish Console.
4. Type source followed by the path and name of the test file you want to run. If you installed IxAutomate using the default path, test files are located on the following path:
/<Tcl install path>/lib/IxAutomate/<suite>/Samples/<test>
For example, to load the RFC2544 Throughput test, type:

source /../lib/IxAutomate/RFC2544/Samples/testTP.tcl
5. Press ENTER to load and run the test.
4-13

Running IxAutomate Tests Unattended
Figure 4-9.
Test Running in Ixwish Console Window

To run an IxAutomate test unattended, use the scheduling application bundled with your operating system (on Unix/Linux, cron; on Windows, Task Scheduler) to run a test at a predetermined time. In Windows, you can configure the complete task in Scheduler. On Unix/Linux, you must write a script and then create a cron job that invokes the script. This section covers the following topics: Windows on page 4-14. Unix/Linux on page 4-16.
Windows
1. Start Task Scheduler (Start | Programs | Accessories | System | Scheduled Tasks). 2. From the menu bar, select File | New | Scheduled Task Task Scheduler adds a new task to the list of scheduled tasks (Figure 4-10).
4-14

Figure 4-10. New Task added to Task List
3. Select the new task, right-click, and select Properties. Task Scheduler displays the properties of the new task. 4. In the Start in: field, enter the path of the directory that contains the test file you want to run. Enclose the path in double-quotes (). IxAutomate executable files are stored in the \Samples subdirectory of each test suite. For example, to run one of the RFC2544 tests, enter:
"C:\Program Files\Ixia\IxAutomate\RFC2544\Samples\"
5. In the Run: field, enter the file path for the Wish Console executable, Enclose the file path in double-quotes. For example, if you installed IxAutomate using the default installation paths, the Wish Console is installed on the following path:
"C:\Program Files\Ixia\wish83.exe"
6. Following the entry for the Wish console in the Run: field, enter the name of the file you want to run. Enclose the file name in double-quotes. For example, to run the RFC2544 Throughput test, enter:
testTP.tcl
4-15

Figure 4-11. IxAutomate Test as Scheduled Task
7. Optionally, enter comments in the Comments field or, in the Run as field, change the user name under which this task is to run (Figure 4-11). 8. Click the Schedule tab and set the schedule for this task. 9. Review the Settings and Security tabs and make any changes necessary for the task to run on your network. 10. When you have finished configuring the task, click Apply, then click OK. Task Scheduler adds the new task. 11. If you want to give the task a more descriptive name than the default New Task, select it in the list, press F2, and enter a new name. 12. If you want to test the task to make sure it runs as you expect, select it in the list, right-click, and select Run.
Unix/Linux
In Unix or Linux, you create a cron job that runs the test. cron is a Unix/Linux system process that executes a program at a preset time. To run a IxAutomate test as a cron job, you create a text file that contains the command to start the Ixia wish shell (ixwish) and the name and path of the test file to be loaded and run. You change the permissions on the text file to make it executable, turning it into a script file. To load the script into cron, you create a text file (the cron job file) that lists the times when you want to run the test and the name of the script file. Then, you use crontab to load the job file into cron. 1. Start a text editor and open a new text file.
4-16

2. Edit the text file to include the commands to start the ixwish shell and load the test. If you installed the Tcl Client (which installed the ixwish shell) and IxAutomate using the default paths, the paths are:
/<Tcl install path>/bin/ixwish /<Tcl install path>/lib/IxAutomate/<suite>/Samples/<test>
For example, to run RFC 2544 Throughput test, enter:

/../bin/ixwish /../lib/IxAutomate/RFC2544/Samples/ testTP.tcl
Make sure both entries are on the same line, and separated by a space. 3. Save the file with a meaningful name. For example, tput. 4. Use the chmod command make the file executable:
chmod a+x <script file name>
For example:
chmod a+x tput
5. In the text editor, create a new text file to list the times the test is to run. This is the cron job file. 6. Edit the file to list the times you want the test to run. The format of a cron job file lists the times a program or script is to run, followed by the name of the program or script, including its path:
[min] [hour] [day of month] [month] [day of week] [program]
Table 4-5 on page 4-18 describes the format. You can create multiple jobs in the cron job file. List each job on a separate line in the job file. For example, to run a test every 15 minutes on every hour, on every day of the month, every month, and every day of the week (in other words, it is to run every 15 minutes for as long as the host computer is up), you would enter:
0,15,30,45 * * * *
To run the test once a day at 3:15am, you would enter:

15 3 * * *
7. Following the times, enter the name and path of the script file you created earlier that contains the command to start ixwish and load a test file. For example,
15 3 * * * /home/ckelly/scripts/tput
8. Type crontab -l to list any jobs that are currently loaded in crontab. If no jobs are listed, then it is safe to load your job. 9. To load the job, type crontab <cron job file>. For example:
crontab tput.cron
10. Confirm that the job was loaded by typing crontab -l. crontab should display something similar to Figure 4-12.
4-17

Figure 4-12. cron Display
cron jobs run under the username that was in effect when you loaded the job in crontab. If you want to change the parameters of the cron job (for example, to change the times that the test is scheduled to run): 1. Edit the cron job file. 2. Unload the existing cron job (crontab -r). 3. Load the updated job file (crontab <cron job file>).
Table 4-5. Parameter [min] cron File Fields Description Number of minutes past the hour when the program is to be run. You can enter a number from 0-59. If you enter an asterisk, (*) the program is run once every minute. Hour when the program is to run, based on a 24-hour clock. Enter a value from 0-23. To run the program every hour, enter an asterisk (*). Day of the month when the program is to run. Enter a value from 1-31. To run the program every day, enter an asterisk (*). Month when the program is to run. Enter a value from 1-12 To run the program every month, enter an asterisk (*). Day of the week when the program is to run. Enter values from 0-6 corresponding to the days of the week: Sunday = 0 Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 To run the program every day of the week, enter an asterisk (*). [program] Program to be executed. Include full path information.
[hour]
[day of month]
[month]
[day of week]
4-18
Chapter 5:
The tests in the RFC 2544 suite are based on RFC 2544 Informational Benchmarking Methodology. The RFC 2544 tests were created to provide network equipment users with a set of standardized, vendor-independent tests that they can use to compare equipment from different vendors. This chapter covers the following topics: Overview of the RFC 2544 - IPv6 Benchmark Test Suite on page 5-1. Back-to-Back on page 5-3. Frame Loss on page 5-10. Latency on page 5-20. Throughput on page 5-27. Troubleshooting the RFC 2544 Tests on page 5-40.
Overview of the RFC 2544 - IPv6 Benchmark Test Suite

This section covers the following topics: Choosing Which Tests to Run on page 5-1. Stacked VLAN (Q in Q) on page 5-2.
Choosing Which Tests to Run
Because each test in the suite tests performance by stressing different parameters, you should run all the tests to gain a comprehensive picture of the DUTs performance. Throughput finds the highest rate at which the DUT can forward frames. Frame Loss tests how the DUT responds to streams with different gaps separating the frames.
5-1

Overview of the RFC 2544 - IPv6 Benchmark Test Suite
Back-to-back tests how the DUT responds to different quantities of frames, with the frames separated by the minimum gap allowed by the protocol specifications. Latency reveals how much processing overhead the DUT requires to forward frames.
The Frame Loss test is somewhat misleadingly named; the Throughput, Frame Loss, and Back-to-back tests all use frame loss as the pass/fail criterion. The Frame Loss test differs from the other two in that it uses a constant number of frames and varies the frame rate and duration. You can run the tests in any order, except for the Latency test, which you should run last. The Latency test depends on the use of a value for the frame rate that does not cause the DUT to drop frames. The RFC 2544 tests use three parameters to characterize a DUT: Frame Rate: the rate at which the test transmits frames Number of Frames: the number of frames the test transmits Duration: the length of time over which the test transmits
Typically, you can specify values for two of these parameters, and the test calculates the values for the third parameter. For example, for the Throughput test, you can specify the frame rate and t duration, and the test calculates the number of frames to transmit. The three parameters interact according to the following formula:
Duration = Number of Frames / Frame Rate
The default duration value is 60 seconds (except for the Frame Loss test). Each test varies either one or two of the parameters to find the DUT performance in handling the remaining parameter. Table 5-1 shows the characteristics of the different tests in the suite.
Table 5-1. RFC 2544 Test Throughput Frame Loss Back-to-back Latency RFC 2544 Tests Frame Rate Varies Varies Constant Number of Frames Varies Constant Varies Duration Constant Varies Varies Measures Latency? No No No Yes
Stacked VLAN (Q in Q)
When using both automatic or manual traffic map, the VLANs parameters may be used to enable the outer VLAN tag (Enable 802.1q Tag) and the inner VLAN tag (Enable stacked VLAN (Q in Q)): If Automatic traffic map is selected:
5-2

Back-to-Back
For the outer VLAN, you can set the First VLAN ID and the Increment VLAN ID (these are available in the Traffic Setup window, Frame Data section); For the stacked VLAN, you can define the First Inner VLAN ID and the Increment Inner VLAN ID (these are available in the Traffic Setup window, Frame Data section).
If Manual traffic map is selected: For the outer VLAN, you can set the VLAN ID, the No. of Addresses, and the Octet to Increment (these are available in the Port Names window, which opens if clicking the Per Port Settings button); For the stacked VLAN, you can define the Inner VLAN ID (it is available in the Port Names window, which opens if clicking the Per Port Settings button).
If the Enable stacked VLAN (Q in Q) option is checked: The Send Mac Only option from the Learning Frames section is automatically activated. ARP is not supported.
For example, the double VLAN tagging can be useful for Internet Service Providers, allowing them to use VLANs internally while handling traffic from clients that is already VLAN tagged.
Table 5-2. Parameter Enable stacked VLAN (Q in Q) First Inner VLAN ID Increment Inner VLAN ID Inner VLAN Parameters Description Applies the inner VLAN settings. The first inner VLAN tag to be assigned If you check this box, the test increments the inner VLAN tag assigned to each port. If you do not check this box, traffic from every port has the same inner VLAN ID. If you check this box, the test compensates the DUTs ability to strip VLAN tags.
Adjust for Tags
Back-to-Back
This test determines the maximum time interval during which the DUT can receive and forward without any frame loss. Frames are sent at a user-specified rate, which is generally the maximum theoretical rate based on the speed of the port. A binary search algorithm is used to obtain the longest duration by the DUT without any packet loss. The transmission rate is kept constant for all iterations.
5-3

Back-to-Back
This test uses pairs of ports with a one-to-one traffic mapping, namely one port transmits to one receive port. The results of the test show the number of back-to-back frames obtained for each frame size and the average and total back-to-back frames for all the trials.
Supported Protocols Features Required on Ports Transmit port Layer2-MAC, IP, IPv6, IPX, VLANs Packet Streams mode Receive port Capture mode
If you select a port for this test that does not support these features, IxAutomate drops that port from the ports list. To determine the features available on your ports, see the Ixia Hardware Guide. Capture mode is available on all ports.
This section covers the following topics: Sample Test Log File on page 5-4. Test Setup: Run Parameters on page 5-8. Test Setup: Other Parameters on page 5-9.
Sample Test Log File

RFC2544 Back to Back test Copyright 1997 - 2001 by IXIA All Rights Reserved. ............................................ Ixia Version 3.50.109 Beta Connecting to Chassis 1: loopback ... mappings for this test. By default, this test uses a bidirectional Creating Maps ... map, so pairs of ports transmit to each other. For example, map add 1 15 1 1 15 2 port 1,15,1 transmits to 1,15,2, and 1,15,2 transmits to 1,15,1. map add 1 15 2 1 15 1 map add 1 15 3 1 15 4 map add 1 15 4 1 15 3 Configuring all ports ... Setting Port speeds, modes and addresses... ===== RFC 2544 Back2back Test, Protocol: MAC, framesize: 64 ===== Checking link states on ports ... Links on all ports are up. 2. After negotiating the link parameters, the test takes Configuring learn frames ... the link down and brings it back up again. Each Ixia port Resetting Statistics ... sends learning frames to the DUT so that the DUT can Sending learning frames from 1.15.1 learn the ports addresses. Sending learning frames from 1.15.2 Sending learning frames from 1.15.3 Sending learning frames from 1.15.4 Transmitted learn frames 1 of 1 seconds Learning frames sent...
1. IxAutomate connects to the chassis and creates the port
5-4

Back-to-Back
******* TRIAL 1 - RFC 2544 Back2back Test ******* Configuring 1.15.1 -> 1.15.2 Configuring 1.15.2 -> 1.15.1 Configuring 1.15.3 -> 1.15.4 Configuring 1.15.4 -> 1.15.3 ---> ITERATION 1, framesize: 64, RFC 2544 Back2back Test Resetting Statistics ... Transmitting frames for 20 seconds Done after 20 seconds...
3. The test calculates the number of frames to transmit based on the port speed (Max. Rate parameter) and on the Duration parameter.
Waiting for Residual frames to settle down for 2 seconds 4. The test allows two seconds for any Waited for 1 of 2 seconds additional frames to come in, then Waited for 2 of 2 seconds begins collecting statistics. Collecting transmit statistics ... 1.15.1: Total frames transmitted: 2976200 1.15.2: Total frames transmitted: 2976200 1.15.3: Total frames transmitted: 2976200 1.15.4: Total frames transmitted: 2976200 Collecting receive statistics ... 1.15.1: Total frames received: 2976200 1.15.2: Total frames received: 2976200 5. One port did not receive all the frames that were 1.15.3: Total frames received: 2976200 transmitted to it. 1.15.4: Total frames received: 2976195 ---> ITERATION 2, framesize: 64, RFC 2544 Back2back Test Resetting Statistics ... Transmitting frames for 20 seconds Done after 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds 6. The test begins searching for the smallest gap Waited for 2 of 2 seconds between frames that allows the failed port to receive Collecting transmit statistics ... all its frames. To test various gap sizes, the test 1.15.1: Total frames transmitted: 2976200 transmission rate is kept constant and the test uses 1.15.2: Total frames transmitted: 2976200 a binary search algorithm to obtain the longest 1.15.3: Total frames transmitted: 1488100 1.15.4: Total frames transmitted: 2976200 duration by the DUT without any packet loss. The Collecting receive statistics ... binary search eventually narrows down to two frame 1.15.1: Total frames received: 2976200 counts that are one frame apart; at the larger one, 1.15.2: Total frames received: 2976200 the port fails, and at the smaller one, it succeeds. 1.15.3: Total frames received: 2976200 1.15.4: Total frames received: 1488096
5-5

Back-to-Back
---> ITERATION 3, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 744050 1.15.4: Total frames received: 744048 ---> ITERATION 4, framesize: 64, RFC 2544 Back2back Test 1.15.3: Total frames transmitted: 372025 1.15.4: Total frames received: 372024 ---> ITERATION 5, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 186012 1.15.4: Total frames received: 186011 ---> ITERATION 6, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 93006 1.15.4: Total frames received: 93004 . ---> ITERATION 7, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 46503 1.15.4: Total frames received: 46503 ---> ITERATION 8, framesize: 64, RFC 2544 Back2back Test Resetting Statistics ... Transmitting frames for 20 seconds Done after 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds 9. After finding a gap size that allows the port to Collecting transmit statistics ... receive all its frames, the test begins binary 1.15.1: Total frames transmitted: 2976200 searching upwards to find the smallest gap size at 1.15.2: Total frames transmitted: 2976200 which the DUT can forward all frames. It searches 1.15.3: Total frames transmitted: 69754 for a gap size between the successful one in the 1.15.4: Total frames transmitted: 2976200 seventh iteration and the previous iteration. Collecting receive statistics ... 1.15.1: Total frames received: 2976200 1.15.2: Total frames received: 2976200 1.15.3: Total frames received: 2976200 1.15.4: Total frames received: 69754
7. For the subsequent iterations, the test continues binary searching downwards by using fewer and fewer frame counts to increase the gap between frames.
8. On the seventh iteration, the failed port received all its frames. The test assumes that at this gap size and at all larger ones, the DUT can forward all the frames.
5-6

Back-to-Back
---> ITERATION 9, framesize: 64, RFC 2544 Back2back Test Resetting Statistics ... Transmitting frames for 20 seconds Done after 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 10. Occasionally, a DUT port that forwarded all its 1.15.1: Total frames transmitted: 2976200 frames on the first iteration drops one or more on a 1.15.2: Total frames transmitted: 2976200 subsequent iteration. The test ignores this and 1.15.3: Total frames transmitted: 81380 continues binary searching on the original port pair. 1.15.4: Total frames transmitted: 2976200 Collecting receive statistics ... 1.15.1: Total frames received: 2976199 1.15.2: Total frames received: 2976200 1.15.3: Total frames received: 2976200 1.15.4: Total frames received: 81379 ---> ITERATION 10, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 75567 1.15.4: Total frames received: 75567 . . ---> ITERATION 20, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 79465 1.15.4: Total frames received: 79465 . . ---> ITERATION 22, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 79466 1.15.4: Total frames received: 79465 ---> ITERATION 21, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 79468 1.15.4: Total frames received: 79467 . . ---> ITERATION 22, framesize: 64, RFC 2544 Back2back Test . 1.15.3: Total frames transmitted: 79466 1.15.4: Total frames received: 79465
11. On the tenth through twentieth iteration, the test continues binary searching upwards by using more frames per transmit period to shrink the gap between each frame. Each iteration is successful.
11. On the twenty-first and twentysecond iterations, the port fails to receive all the transmitted frames. Up to this point, the largest number of frames that the port pair could transmit through the DUT without loss was 79465 on iteration 20. The test begins binary searching back towards 79465.
5-7

Back-to-Back
---> ITERATION 23, framesize: 64, RFC 2544 Back2back Test Resetting Statistics ... Transmitting frames for 20 seconds Done after 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds 12. On the twenty-third iteration, the test transmits Collecting transmit statistics ... the same number of frames that the port previously 1.15.1: Total frames transmitted: 2976200 received successfully, 79465. Based on this, it 1.15.2: Total frames transmitted: 2960758 determines that 79465 is the largest number of 1.15.3: Total frames transmitted: 79465 frames that can be forwarded by that port pair. 1.15.4: Total frames transmitted: 2976200 Collecting receive statistics ... Note that port 1,15,2 transmitted fewer frames than 1.15.1: Total frames received: 2960758 1,15,1 or 1,15,3. This is probably because port 1.15.2: Total frames received: 2976200 1,15,2 had to re-transmit some frames due to 1.15.3: Total frames received: 2976200 collisions, and ran out of time before it transmitted 1.15.4: Total frames received: 79464 all its frames. Saving results for Trial 1 ... RFC 2544 Back2back Test - MAC --> Framesize: 64 TX RX B2bFrames ************************************** 1.15.1 1.15.2 2976200 1.15.2 1.15.1 2976200 1.15.3 1.15.4 79465 1.15.4 1.15.3 2976200 ************************************** %MaxRate = 100 Total Back2back = 9008065 Tolerance(%) = 0
13. The results for the back-to-back test display the largest numbers of frames each port received without any frame loss. The results also display the most important test configuration details and the total number of frames received by all ports on the last iteration.
Test Setup: Run Parameters
Table 5-3. Parameter Duration
RFC 2544 Back-to-Back Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency (the default value is 50). If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time.
No. of Trials
Staggered Transmit
Sequence Errors
If you check this box, the number of sequence errors in the traffic received from the DUT is calculated.
5-8

Back-to-Back
RFC 2544 Back-to-Back Test Run Parameters (Continued) Description The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Loss Tolerance (%)
Resolution
This parameter is available only when the binary search algorithm is used. The difference between the real rate transmission, expressed as a percentage, in two consecutive iterations, is compared with the resolution value. When the difference between the load rate values in two consecutive iterations is smaller than the specified value for the resolution, the test stops. Init rate is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s). megabits per second (Mbps) gigabits per second (Gbps) kilobytes per second (KBps) megabytes per second (MBps) gigabytes per second (GBps). Note that these rates are the traffic bit rate without the preamble. percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which the frames are transmitted. Use caution when specifying low rates; the test can become less accurate if the frame rate nears 1 f/s.
Init Rate
Report Unit Rate
Select the report unit rate to display data in a particular unit. You can select kilobits per second, (kbps) megabits per second (Mbps), gigabits per second (Gbps), kilobytes per second (KBps), megabytes per second (MBps), gigabytes per second (GBps), and frames per second (fps). When you select any unit other than megabits per second (Mbps), an additional column is displayed in iteration.csv, results.csv, and Aggregateresults.csv displaying the data in the selected unit.
Test Setup: Other Parameters
Protocol: See Configuring IP, IPX, and MAC Addresses on page 3-18.
Additionally, when choosing the IP or IPv6 protocols, you can select: The encapsulation protocol over IP: UDP, TCP, or None. The TCP/UDP port used to send traffic: Source Port The TCP/UDP port used as destination: Destination Port
5-9

Frame Loss
If you check the Increment Port option, the TCP/UDP port number is incremented for each Tx-Rx port pair used in the test configuration. This means that the TCP/UDP port number increments per stream.
Frame Size: Specify the size of the frames to transmit. For more information about frame sizes, see Choosing Frame Sizes on page 3-45. Learning Frames: See Configuring Learning Frames on page 3-23. Traffic Map: See Setting Up the Traffic Map on page 3-11. VLANs: See Setting the VLAN Parameters on page 3-42 and How IxAutomate
Assigns VLAN IDs on page 3-43. For information about double VLAN tagging, see Stacked VLAN (Q in Q) on page 5-2.
Notes: 1. If you set the listed parameters as follows: The Protocol to IP or IPv6 protocol, The Traffic Map to Automatic mode, The Direction to Unidirectional, Enable the Echo Map, two parameters become available: Use different destination IP address for Echo Map and Destination IP/IPv6 Address. If you enable Use different destination IP address for the Echo Map check box, a destination IP address may be set in the Destination IP/IPv6 Address parameter field. It must be a different IP address from the one used for transmission. It is useful when you have only one port available. 2. If you set the Protocol to MAC protocol, the Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device. 3. For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports.
Frame Loss
This test determines how many frames the DUT loses at various frame rates. This test uses pairs of ports with a one-to-one traffic mapping, that is, one port transmits to one receive port. You can specify the number of frames to transmit, how to transmit the traffic (constant loading or bursty loading), the initial transmit rate, and the percentage of decrease in the frame rate (the Granularity parameter) for each iteration. The fine granularity selection uses one-percent decreases in the frame rate, while the coarse selection uses ten-percent decreases. Starting with the initial frame rate, the test transmits the specified number of frames, counts the received number (the number the DUT can forward). If the DUT cannot forward all the frames, the test decreases the frame rate and transmits again. This process continues until the test finds a rate at which the DUT can
5-10

Frame Loss
forward all the frames it receives. This test is configured with a one-to-one traffic mapping. The results of the test show the frame loss for various rates for each frame size.
Supported Protocols Features Required on Ports Transmit port MAC, IP, IPv6, IPX, IP/ IPv6, VLANs Packet Streams mode Receive port Capture mode
This section covers the following topics: Sample Test Log File on page 5-11. IPv6 Extension Headers on page 5-18. Test Setup: Other Parameters on page 5-19.

>>>>>>> Start Time: Friday, Dec 21, 2001 12:26:18 AM RFC2544 Frame Loss test Copyright 1997 - 2001 by IXIA All Rights Reserved. ............................................ Connecting to Chassis 1: loopback ... Creating Maps ... 1. IxAutomate connects to the chassis and creates the map add 1 1 1 1 1 2 port mappings for this test. As the other tests in the RFC map add 1 1 2 1 1 1 map add 1 1 3 1 1 4 2544 suite, the Frame Loss test uses a bidirectional map add 1 1 4 1 1 3 map, with pairs of ports transmitting to each other. map add 1 2 1 1 2 2 map add 1 2 2 1 2 1 map add 1 2 3 1 2 4 map add 1 2 4 1 2 3 Configuring all ports ... Setting Port speeds, modes and addresses...
5-11

Frame Loss
===== RFC 2544 Frameloss Test with coarse granularity, Protocol: MAC, framesize: 64 ===== Checking link states on ports ... 2. After negotiating the link parameters, the test takes Links on all ports are up. the link down and brings it back up again. Each port Configuring learn frames ... sends learning frames to the DUT so that the DUT can Resetting Statistics ... learn the Ixia ports addresses. Sending learning frames from 1.1.1 Sending learning frames from 1.1.2 The protocol selected for this test is MAC, so it sends Sending learning frames from 1.1.3 MAC frames. If the protocol were IP, it would send ARP Sending learning frames from 1.1.4 requests. If the protocol were IPX, it would send RIPX Sending learning frames from 1.2.1 requests. Sending learning frames from 1.2.2 Sending learning frames from 1.2.3 Sending learning frames from 1.2.4 Transmitted learn frames 1 of 1 seconds Learning frames sent... ******* TRIAL 1 Configuring 1.1.1 Configuring 1.1.2 Configuring 1.1.3 Configuring 1.1.4 Configuring 1.2.1 Configuring 1.2.2 Configuring 1.2.3 Configuring 1.2.4 RFC 2544 Frameloss Test with coarse granularity ******* -> 1.1.2 3. Configuring means that the test is building the packet streams -> 1.1.1 for each port. -> 1.1.4 -> 1.1.3 -> 1.2.2 -> 1.2.1 -> 1.2.4 -> 1.2.3
---> ITERATION 1, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for < 1 second 4. The test takes less than 1 second to transmit the default 100,000 frames to each port at the initial rate of 100% of the maximum port sp Done after 0 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.1.1: Total frames transmitted: 100000 1.1.2: Total frames transmitted: 100000 1.1.3: Total frames transmitted: 100000 1.1.4: Total frames transmitted: 100000 1.2.1: Total frames transmitted: 100000 1.2.2: Total frames transmitted: 100000 1.2.3: Total frames transmitted: 100000 1.2.4: Total frames transmitted: 100000 Collecting receive statistics ... 1.1.1: Total frames received: 50403 1.1.2: Total frames received: 50364 5. For the first iteration, the DUT can 1.1.3: Total frames received: 50385 1.1.4: Total frames received: 50383 forward about half of the frames that it 1.2.1: Total frames received: 50375 received. 1.2.2: Total frames received: 50371 1.2.3: Total frames received: 50386 1.2.4: Total frames received: 50387
5-12

Frame Loss
---> ITERATION 2, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for < 1 second Done after 0 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.1.1: Total frames transmitted: 100000 1.1.2: Total frames transmitted: 100000 1.1.3: Total frames transmitted: 100000 1.1.4: Total frames transmitted: 100000 1.2.1: Total frames transmitted: 100000 1.2.2: Total frames transmitted: 100000 1.2.3: Total frames transmitted: 100000 1.2.4: Total frames transmitted: 100000 Collecting receive statistics ... 1.1.1: Total frames received: 56560 6. For the second iteration, the test reduces the transmit rate, 1.1.2: Total frames received: 56586 so the DUT loses fewer frames. For this example, the 1.1.3: Total frames received: 56579 Granularity parameter is set to Coarse, meaning that it 1.1.4: Total frames received: 56580 reduces the transmit rate by increments of 10% of the initial 1.2.1: Total frames received: 56587 rate. If it had been set to Fine granularity, it would reduce the 1.2.2: Total frames received: 51472 rate by increments of 1%. 1.2.3: Total frames received: 56561 1.2.4: Total frames received: 56558 ---> ITERATION 3, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for < 1 second 7. For the subsequent iterations, the test continues . . . reducing the transmit rate, searching for a rate at which Collecting transmit statistics ... the DUT can forward all the frames it receives. 1.1.1: Total frames transmitted: 100000 . . . Collecting receive statistics ... 1.1.1: Total frames received: 62959 ---> ITERATION 4, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for < 1 second . . . Collecting transmit statistics ... 1.1.1: Total frames transmitted: 100000 . . . Collecting receive statistics ... 1.1.1: Total frames received: 71962 ---> ITERATION 5, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for 1 seconds . . . Collecting transmit statistics ... 1.1.1: Total frames transmitted: 100000 . . . Collecting receive statistics ... 1.1.1: Total frames received: 83977
5-13

Frame Loss
---> ITERATION 6, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for 1 seconds . . . Collecting transmit statistics ... 1.1.1: Total frames transmitted: 100000 . . . Collecting receive statistics ... 1.1.1: Total frames received: 99998 ---> ITERATION 7, framesize 64, RFC 2544 Frameloss Test with coarse granularity Resetting Statistics ... Transmitting frames for 1 seconds Done after 1 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.1.1: Total frames transmitted: 100000 1.1.2: Total frames transmitted: 100000 1.1.3: Total frames transmitted: 100000 1.1.4: Total frames transmitted: 100000 1.2.1: Total frames transmitted: 100000 1.2.2: Total frames transmitted: 100000 1.2.3: Total frames transmitted: 100000 1.2.4: Total frames transmitted: 100000 Collecting receive statistics ... 1.1.1: Total frames received: 100000 1.1.2: Total frames received: 100000 1.1.3: Total frames received: 100000 8. On the seventh iteration, the DUT is able to 1.1.4: Total frames received: 100000 forward all the frames it received. The test ends 1.2.1: Total frames received: 100000 and prints the results. 1.2.2: Total frames received: 100000 1.2.3: Total frames received: 100000 1.2.4: Total frames received: 100000 RFC 2544 Frameloss Test with coarse granularity --> Framesize: 64, protocol - MAC test TX RX Tx frames Rx frames Rate (%)Frame Loss% ******************************************************************************************** ******* 9. The test prints the 1.1.1 1.1.2 100000 100000 74405 50.00 0.000 results of each iteration 1.1.1 1.1.2 100000 83979 89286 60.00 16.021 for each port pair. The 1.1.1 1.1.2 100000 71959 104167 70.00 28.041 statistics shown in the 1.1.1 1.1.2 100000 62948 119048 80.00 37.052 results include the number 1.1.1 1.1.2 100000 56586 133690 89.84 43.414 of frames transmitted, the 1.1.1 1.1.2 100000 50364 148810 100.00 49.636 number of frames . received (forwarded by . the DUT), the transmit . 1.2.4 1.2.3 100000 100000 74405 50.00 0.000 rate in f/s, the transmit 1.2.4 1.2.3 100000 83981 89286 60.00 16.019 rate as a percentage of 1.2.4 1.2.3 100000 71963 104167 70.00 28.037 maximum port speed, and 1.2.4 1.2.3 100000 62969 119048 80.00 37.031 the frame loss 1.2.4 1.2.3 100000 56561 133690 89.84 43.439 percentage. 1.2.4 1.2.3 100000 50386 148810 100.00 49.614 ******************************************************************************************** *******
5-14

Frame Loss
RFC 2544 Frame Loss Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. Choose the trial duration for the test. The available options are: No. of Frames it allows you to change the number of frames that the test uses and it disables the Duration parameter. Duration it enables the Duration parameter and disables the No. of Frames parameter.
No. of Trials
Run Mode
No. of Frames Granularity
The number of frames to transmit in each iteration. This parameter determines the size of the change in frame rate when the test searches for an ideal rate. If you select Coarse, the test adjusts the frame rate in steps of 10% at a time. If you select Fine, the test adjusts the frame rate in steps of 1% at a time.
Traffic Profile
This allows you to choose how the traffic is sent. You can select one of the following options: Constant Loading Bursty Loading Constant loading is the equivalent of transmitting steady traffic. Transmitting bursty traffic means that the traffic is transmitted in successive bursts.
Burst Size (# of frames)
The number of frames contained in each burst. If you set the value to 1, it means that the traffic is transmitted as constant loading. For a value larger than 1, the test is running with bursty traffic. The minimum value for burst size is 1.
5-15

Frame Loss
RFC 2544 Frame Loss Test Run Parameters (Continued) Description The number of frames that could be transmitted during the desired gap period of time, at the specified rate. The minimum value you can set from the graphical user interface is 1. If you are running the test from the command line for a value lower than or equal to 0, the test is aborted with an error message. For example, having the following settings: Frame Size=64; Load Rate=10; Traffic Profile=Bursty Loading; Burst Size (# of frames)=5; Frames per Burst=2; The period of time equivalent with the time for transmitting 2 frames, having the size set to 64 and the load rate set to 10% is equal to 115.2 ns.
Frames Per Burst Gap
Staggered Transmit
If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time.
Sequence Errors Init Rate
If you check this box, the number of sequence errors in the traffic received from the DUT is calculated. Init rate is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s). megabits per second (Mbps) gigabits per second (Gbps) kilobytes per second (KBps) megabytes per second (MBps) gigabytes per second (GBps). Note that these rates are the traffic bit rate without the preamble. percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which the frames are transmitted. Use caution when specifying low rates; the test can become less accurate if the frame rate nears 1 f/s.
IPv6 Extension Header
The IPv6 traffic may contain extension headers. For more information about extension headers, see IPv6 Extension Headers on page 5-18.
5-16

Frame Loss
RFC 2544 Frame Loss Test Run Parameters (Continued) Description It allows you to measure the DUT performance of mixed IPv4 and IPv6 environments. If you set the IP/ IPv6 protocol in the in Frame Data section, the test creates both IPv4 and IPv6 streams. The test applies the values you select for the IPv4 and IPv6 parameters in the IPv4/IPv6 Ratio parameter field to the Load Rate value, as a percentage of the total traffic sent. For example, if you set IPv4 to 10, IPv6 is set, by default, to 90 (the sum of the two parameters is always 100). If the Load Rate is set to 50%, the test transmits IPv4 traffic at 5% of the load rate (10% of 50 =5) and IPv6 traffic at 45% of the load rate (90% of 50= 45).
IP/IPv6 Ratio
Report Unit Rate
Select the report unit rate to display data in a particular unit. You can select kilobits per second, (kbps) megabits per second (Mbps), gigabits per second (Gbps), kilobytes per second (KBps), megabytes per second (MBps), gigabytes per second (GBps), and frames per second (fps). When you select any unit other than megabits per second (Mbps), an additional column is displayed in iteration.csv, results.csv, and Aggregateresults.csv displaying the data in the selected unit.
Pass Criteria Pass Criteria If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kbps) megabits per second (Mbps), gigabits per second (Gbps), kilobytes per second (KBps), megabytes per second (MBps), gigabytes per second (GBps), frames per second (fps). Note that the rate is the traffic bit rate without the preamble. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
5-17

Frame Loss
IPv6 Extension Headers
For the generated IPv6 traffic, extension headers may be added in order to test more completely and realistically the DUTs IPv6 performance. The available extension header types are: Hop-by-hop options header Destination options header Routing header Fragment header Authentication header
The IxAutomate test offers you three options for IPv6 traffic configuration: no extension header one extension header selected from the extension header type list a chain of extension headers selected from the extension header type list
Note: The hop-by-hop header cannot be contained within a chain of extension headers because this header must be processed by each node that forwards the traffic. Tests with traffic containing this extension headers type measures the DUT performance in terms of resources and not in terms of throughput values.
When choosing to set a chain of extension headers for the IPv6 packets, you can set, for example: 1. Routing header (24-32 bytes) 2. Destination options header (8 bytes) 3. Fragment header (8 bytes) The IPv6 extension headers section (Figure 5-1) available in the Test Setup tab allows you to: add IPv6 extension headers (using the Add button). For more information, see Adding an IPv6 Extension Header on page 5-19. remove IPv6 extension headers (using the Delete button) change the IPv6 extension headers order (using the Up and Down buttons)
Figure 5-1.
IPv6 Extension Headers
5-18

Frame Loss
Adding an IPv6 Extension Header To add an IPv6 extension header: 1. Click the Add button. The Add IPv6 Extension Header dialog window opens (Figure 5-2).
Figure 5-2.
Add IPv6 Extension Header Dialog Window
2. Choose an extension header type from the available list. Different header options are available for each of them. 3. Set the desired values for each header option. 4. Click OK.
Protocol: See Configuring IP, IPX, and MAC Addresses on page 3-18. Notes: 1. If you set the Protocol to MAC protocol, the Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device. 2. For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option helps with better address distribution for different tests with different excluded ports.
5-19

Latency
Frame Size: Specify the size of the frames to transmit. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Learning Frames: See Configuring Learning Frames on page 3-23. Traffic Map: See Setting Up the Traffic Map on page 3-11. VLANs: See Setting the VLAN Parameters on page 3-42 and How IxAutomate
Latency
This test determines the latency of the DUT. In the Latency test, frames are transmitted for a fixed duration. Once per second, the test tags a frame and transmits it halfway through the duration time. The test compares the tagged frame timestamp when it was transmitted with the timestamp when it was received. The difference between the two timestamps is the latency. The Latency test can tolerate some frame loss, because it uses only the tagged frames to measure latency, discarding the remaining untagged frames. However, to be certain of accurate results, you must configure the test with a frame rate at which the DUT does not lose packets. If the DUTs maximum throughput rate is not known, then first run the Throughput test. Use the results from the Throughput test to choose a frame rate for the Latency test. This test is configured with a one-to-one traffic mapping. The results of the test show the latencies for each frame size and the average latencies for all the trials.
This section covers the following topics: Sample Test Log File on page 5-21. Test Setup: Run Parameters on page 5-22. Test Setup: Other Parameters on page 5-25. Port Setup Parameters on page 5-26. Troubleshooting the Latency Test on page 5-26.
5-20

Latency

RFC2544 Latency test Copyright 1997 - 2001 by IXIA All Rights Reserved. ............................................
Ixia Version 3.50.109 Beta Connecting to Chassis 1: loopback ... mappings for this test. By default, this test uses a Creating Maps ... bidirectional map, so the pairs of ports transmit to each map add 1 15 1 1 15 2 other. For example, port 1,15,1 transmits to 1,15,2, and map add 1 15 2 1 15 1 1,15,2 transmits to 1,15,1. map add 1 15 3 1 15 4 map add 1 15 4 1 15 3 Configuring all ports ... Setting Port speeds, modes and addresses... ===== RFC 2544 Latency Test, Protocol: MAC, Checking link states on ports ... Links on all ports are up. Configuring learn frames ... Resetting Statistics ... Sending learning frames from 1.15.1 Sending learning frames from 1.15.2 Sending learning frames from 1.15.3 Sending learning frames from 1.15.4 Transmitted learn frames 1 of 1 seconds Learning frames sent... framesize: 64 =====
1. IxAutomate connects to the chassis and creates the port
2. After negotiating the link parameters, the test takes the link down and brings it back up again. Each port sends learning frames to the DUT so that the DUT can learn the Ixia ports addresses.
******* TRIAL 1, framesize: 64 - RFC 2544 Latency Test ******* Configuring 1.15.1 -> 1.15.2 Configuring 1.15.2 -> 1.15.1 Configuring 1.15.3 -> 1.15.4 Configuring 1.15.4 -> 1.15.3 3. The test calculates the number of frames to transmit Resetting Statistics ... based on the port speed (Max. Rate parameter) and Transmitting frames for 20 seconds the Duration parameter. Done after 20 seconds... Waiting for Residual frames to settle down for 2 seconds 3. The test allows two seconds for any Waited for 1 of 2 seconds additional frames to come in, then Waited for 2 of 2 seconds begins collecting statistics. Collecting transmit statistics ... 1.15.1: Total frames transmitted: 1488100 4. The test reports the number of transmitted frames, 1.15.2: Total frames transmitted: 1488100 but unlike the other tests in the suite, it does not 1.15.3: Total frames transmitted: 1488100 1.15.4: Total frames transmitted: 1488100 compare the numbers of transmitted and received Saving results for Trial 1 ... frames. Therefore, it is important to run the Throughput,
Frame Loss, and Back-to-back tests first to find a combination of port speed (Max Rate) and Duration at which the DUT forwards frames without any loss.
5-21

Latency
RFC 2544 Latency Test - MAC --> Framesize: 64 TX RX Latency(ns) ************************************** 1.15.1 1.15.2 11080 5. The test displays the latencies for each port and the 1.15.2 1.15.1 10480 average latency of all four ports. 1.15.3 1.15.4 13520 1.15.4 1.15.3 12600 ************************************** %MaxRate = 50 AvgLatency(ns) = 11920
RFC 2544 Latency Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. This allows you to choose how the traffic is sent. You can select one of the following options: Constant Loading Bursty Loading Constant loading is equivalent to transmitting steady traffic. Transmitting bursty traffic means that the traffic is transmitted in successive bursts.
No. of Trials
Traffic Profile
Burst Size (# of frames)
The number of frames contained in each burst. If you set the value to 1, it means that the traffic is transmitted as constant loading. For a value larger than 1, the test is running with bursty traffic. The minimum value for burst size is 1.
5-22

Latency
RFC 2544 Latency Test Run Parameters (Continued) Description The number of frames that could be transmitted during the desired gap period of time, at the specified rate. The minimum value you can set from the graphical user interface is 1. If you are running the test from the command line for a value lower than or equal to 0, the test is aborted with an error message. For example, having the following settings: Frame Size=64; Load Rate=10; Traffic Profile=Bursty Loading; Burst Size (# of frames)=5; Frames per Burst=2; the period of time equivalent with the time for transmitting 2 frames, having the size 64 and the load rate is set to 10% is equal to 115.2 ns.
Calibrate Latency
If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. This option is available if the IxOS version used is at least 5.10.
Latency Type
Selects the method used to calculate latency: Cut Through: Delay between the time the first bit of the test frame leaves the Ixia TX port and the time it arrives on the Ixia RX port. Cut Through is normally used with switches and other devices that operate using packet header information. 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: Delay between the time the last bit of the test frame leaves the Ixia TX port and the time its first bit arrives on the Ixia RX port. Store and forward latency is calculated by first determining the Cut Through delay and then substracting the frame length time. Store and Forward is normally used with routers and other devices that operate on the contents of the entire packet. The last transmitted data bit is usually the end of the FCS or CRC, and the first data bit received is as described above for Cut Through.
5-23

Latency
RFC 2544 Latency Test Run Parameters (Continued) Description If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time.
Staggered Transmit
Sequence Errors Init Rate
If you check this box, the number of sequence errors in the traffic received from the DUT is calculated. Init rate is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s). megabits per second (Mbps) gigabits per second (Gbps) kilobytes per second (KBps) megabytes per second (MBps) gigabytes per second (GBps). Note that these rates are the traffic bit rate without the preamble. percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which the frames are transmitted. Use caution when specifying low rates; the test can become less accurate if the frame rate nears 1 f/s.
IP/IPv6 Ratio
It allows you to measure the DUT performance of mixed IPv4 and IPv6 environments. If you set the IP/ IPv6 protocol in the Frame Data section, the test creates both IPv4 and IPv6 streams.The test applies the values you select for the IPv4 and IPv6 parameters in the IP/IPv6 Ratio parameter field to the Load Rate value, as a percentage of the total traffic sent. For example, if you set IPv4 to 10, IPv6 is set, by default, to 90 (the sum of the two parameters is always 100). If the Load Rate is set to 50%, the test transmits IPv4 traffic at 5% of the load rate (10% of 50 =5) and IPv6 traffic at 45% of the load rate (90% of 50= 45).
The IPv6 traffic may contain extension headers. For more information about extension headers, see IPv6 Extension Headers on page 5-18.
5-24

Latency
RFC 2544 Latency Test Run Parameters (Continued) Description Select the report unit rate to display data in a particular unit. You can select kilobits per second, (kbps) megabits per second (Mbps), gigabits per second (Gbps), kilobytes per second (KBps), megabytes per second (MBps), gigabytes per second (GBps), and frames per second (fps). When you select any unit other than megabits per second (Mbps), an additional column is displayed in iteration.csv, results.csv, and Aggregateresults.csv displaying the data in the selected unit.
Report Unit Rate
Pass Criteria Pass Criteria If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Latency
Ports: See Setting Up Ports on page 3-7 for the common settings. For the parameters that are unique for this test, see Port Setup Parameters on page 526. Protocol: See Configuring IP, IPX, and MAC Addresses on page 3-18.
5-25

Latency
Notes: 1. If you set the Protocol to MAC protocol, the Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device. 2. For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option helps with better address distribution for different tests with different excluded ports.
Port Setup Parameters
Table 5-6 lists the port setup parameters that are different from the standard settings or unique for this test.
Table 5-6. Parameter Transceiver Latency Test - Port Setup Parameters Description Depending on the card type, the drop-down list contains different types of transceivers for which the Latency was already measured (for example, some 10G Ethernet card). By choosing one of the available Transceivers, the Latency parameter field is filled in with the already measured value (in nanoseconds) and is no longer unavailable for editing. For other cards, no transceiver types were measured and because of that, the only option available in the drop-down list is Other... Latency The measured time for the specified transceiver (expressed in nanoseconds)
Troubleshooting the Latency Test
If latency numbers for your DUT seem too high, that can be an indication that the DUTs buffers are overflowing. To reduce the aggregate number of frames sent to the DUT, try reducing the offered load by lowering the frame rate or decreasing the number of ports used in the test.
5-26

Throughput
Very high frame rates can cause long and unpredictable latencies due to over- or under-speed clocking issues between the DUT and the Ixia chassis.
Throughput
This test determines the maximum rate at which the DUT receives and forwards frames without any frame loss. Frames are initially sent at a user-specified rate, generally the maximum theoretical rate based on the speed of the port. A binary search algorithm is used to obtain a rate at which the DUT does not lose any frames. This test is configured with a one-to-one traffic mapping. The results of the test show the throughput rates in frames per second (f/s) obtained for each frame size.
This section covers the following topics: General Information About the Test on page 5-27. How the Binary Search Works on page 5-28. Frames Counted During the Test on page 5-28. Transmit Rates on page 5-28. How the Test Determines Average Transmit Rates on page 5-29. Common Causes for Throughput Not Meeting Expectations on page 5-29. Sample Test Log File on page 5-30. Test Setup: Run Parameters on page 5-35. Test Setup: Other Parameters on page 5-39.
General Information About the Test
The Throughput test transmits traffic at the highest rate configured on its first attempt. The rate is configured as a percentage of the maximum port speed. When the duration has elapsed, it stops transmitting and compares the number of received frames with the sent number. If the number of received frames equals the number of transmitted frames, the test considers that run to be a success, and moves on to test the next frame size. If the number of received frames does not match the number of transmitted frames, the test retransmits at a lower rate for the time defined by the Duration
5-27

Throughput
parameter. The test again compares the numbers and if they match, it retransmits at a higher rate. If they do not match, it retransmits at a lower rate.
How the Binary Search Works
The Throughput test finds the highest rate at which the DUT can forward frames without losing any. To do this, it uses a simple binary search algorithm to choose rates halfway between the previous rate and a new rate. If a port pair drops frames, it searches downwards for a lower rate. If a port pair does not drop frames, it searches upwards for a higher rate. To choose a lower rate, the test divides the previous rate in half, and uses the result as the new rate. To find a higher rate, it divides the previous rate in half and adds it to the previous rate. The test searches among higher and lower rates until it finds the rate at which no frames are lost. For example, if a port pair drops frames at a rate of 100 percent, the new rate is 50 percent. If frames are still lost at 50 percent, the test retransmits at 25 percent. It repeatedly retransmits with progressively lower rates until either the transmit speed drops below 100 f/s, or no frames are lost. If the transmit speed drops to 100 f/s, the test ends, on the assumption that something must be severely wrong with the DUT or network. If no frames are lost, the test begins binary searching upwards to find the highest rate with no frame loss. For example, if frames are lost at 100 percent and the test retransmits at 50 percent with no loss, the test retransmits again at 75 percent. If frames are lost at 75 percent, it retransmits at 62.5 percent. If no frames are lost at 62.5 percent, it retransmits at 68.75 percent, and so on. The binary search process continues until the test finds the rate, within the specified tolerance, at which no frames are lost.
Frames Counted During the Test
The test can discriminate between frames sent from the Ixia tester and frames sent from other devices. The Ixia transmit port inserts a tag into the data payload of each frame it transmits. This tag is unlikely to be duplicated by other devices on the network, if any. The Ixia receive ports only count frames with that tag at the proper place in the frame. This protects the integrity of the test by not counting extraneous frames as part of the test. For example, if during the test, the DUT generates management frames, the test ignores them. Even though the test does not count frames it did not generate, but the smallest amount of non-test traffic may affect the throughput results. Therefore, you should make sure that no significant amounts of background traffic are present on the test network. The throughput test does nothing more than compare the received frames with the transmitted frames; it does not care how the frames arrived at their destination; it only cares whether they arrived or not.
Transmit Rates
To transmit frames, the test programs the transmit ports to transmit a frame count, with each frame separated by a gap. Based on the configured transmit rate (percentage of maximum port speed) and duration (how long the test transmits),
5-28

Throughput
the test calculates the gap (at 100 percent port speed, the gap is minimal). Based on the duration and the gap, the test calculates the number of frames to transmit. For example, consider the following scenario: The test programs the transmit port to transmit for 10 seconds (s) with a given gap. Assume that 10 seconds (s) works out to 100 packets to transmit.
packet packet packet packet packet packet packet . . . packet 1 2 3 3 3 4 5 --> --> --> --> --> --> --> OK OK collision collision OK OK OK
100 -->OK
Due to the number of collisions, it took the transmitter more than 10 seconds to transmit the 100 frames. However, the test does not query the transmit port to find out for how long it has transmitted. The test assumes the transmitter transmitted for 10 seconds, and displays that as Transmitting frames for 10 seconds in the log file. Therefore, %MaxTxRate displays 100 percent, while AvgTxRunRate reveals that, due to the collisions, the port actually transmitted at some lower rate.
How the Test Determines Average Transmit Rates
To calculate the DUTs average transmit rates, the test takes a sample of the transmit rates halfway through the test. If you run the test several times, you may find that the total number of transmitted and received frames match for each test, but the average transmit rates do not. This can be caused by differences in the DUTs internal processing capability at the time the samples are taken. For example, if the DUT happens to be forwarding frames relatively slowly at the halfway point in the test, the test reports average transmit rates lower than those reported if the average were calculated over the entire duration of the test. The Throughput test results are based solely on a comparison of sent frames with received frames. If the test results show that the throughput you expected was not obtained, there is only one cause: dropped frames. Frames can be dropped for many reasons, but the main causes are: the DUT is not set up as described by RFC 2544 the test is run with management features turned on
Common Causes for Throughput Not Meeting Expectations
If you enable software features that RFC 2544 says should be disabled, they adversely affect the test results. Refer to RFC 2544 and make sure that your DUT is set up in accordance with it. When working with Ethernet devices, the calculated maximum throughput rate may not show 100% even when a device fully complies with the IEEE 802.3 and 802.3z standards. This is due to the tolerance allowed within these standards. and the accuracy of the Ixia port clocks. An application note entitled Ethernet Perfor-
5-29

Throughput
mance Measurement available on Ixias Web site (http://www.ixiacom.com) describes this issue in detail.

RFC2544 Throughput test Copyright 1997 - 2001 by IXIA All Rights Reserved. ............................................ Connecting to Chassis 1: loopback ... 1. IxAutomate connects to the chassis and creates the port Creating Maps ... mappings for this test. By default, this test uses a bidirectional map add 1 2 1 1 2 2 map, so the pairs of ports transmit to each other. For example, map add 1 2 2 1 2 1 port 1,2,1 transmits to 1,2,2, and 1,2,2 transmits to 1,2,1. map add 1 2 3 1 2 4 map add 1 2 4 1 2 3 Configuring all ports ... Setting Port speeds, modes and addresses... ===== RFC 2544 Throughput Test, Protocol: Checking link states on ports ... Links on all ports are up. Configuring learn frames ... Resetting Statistics ... Sending learning frames from 1.2.1 Sending learning frames from 1.2.2 Sending learning frames from 1.2.3 Sending learning frames from 1.2.4 Transmitted learn frames 1 of 1 seconds Learning frames sent... MAC, framesize: 64 =====
2. After negotiating the link parameters, the test takes the link down and brings it back up again. Each port sends learning frames to the DUT so that the DUT can learn the Ixia ports addresses. The protocol selected for this test is MAC, so it sends MAC frames. If the protocol were IP, it would send ARP requests. If the protocol were IPX, it would send RIPX requests.
******* TRIAL 1 - RFC 2544 Throughput Test ******* Configuring 1.2.1 -> 1.2.2 Configuring 1.2.2 -> 1.2.1 Configuring 1.2.3 -> 1.2.4 Configuring 1.2.4 -> 1.2.3 ---> BINARY ITERATION 1, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2976200 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 1.2.4: Total frames transmitted: 2976200
3. The test allows two seconds for any additional frames to come in, then begins collecting statistics.
5-30

Throughput
Collecting receive statistics 1.2.1: Total frames received: 1.2.2: Total frames received: 1.2.3: Total frames received: 1.2.4: Total frames received:
... 2976200 2976192 2976200 2976200
4. One port did not receive all the frames that were transmitted to it. 5. OLoad is the offered load, expressed in frames per second (f/s). %MaxTxRate is the rate (expressed as a percentage of port speed) at which the test programmed the transmitter to transmit. The transmitter may not have actually transmitted at this rate if it took longer than anticipated to transmit the calculated number of frames.
Configured Transmit Rates used for iteration 1 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 148810 100.00 148809 148804 6. AvgTxRunRate and AvgRxRunRate 1.2.2 1.2.1 148810 100.00 148809 148804 are the measured speeds at which the 1.2.3 1.2.4 148810 100.00 148810 148804 ports transmitted and received frames. 1.2.4 1.2.3 148810 100.00 148810 148804 ******************************************************************************************** ---> BINARY ITERATION 2, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 1488100 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 1.2.4: Total frames transmitted: 2976200 7. For the second pass, the test reduced the transmit Collecting receive statistics ... rate to half the previous rate for the port pair that lost 1.2.1: Total frames received: 2976200 frames (see %MaxTxRate below). The receive port of 1.2.2: Total frames received: 1488100 that pair got all its frames, but another pair lost frames. 1.2.3: Total frames received: 2976200 The test does not reduce their rate; once a port pair 1.2.4: Total frames received: 2966682
passes the first iteration, it is never tested again.
Configured Transmit Rates used for iteration 2 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 74405 50.00 74404 74404 1.2.2 1.2.1 148810 100.00 148809 148807 1.2.3 1.2.4 148810 100.00 148809 148807 1.2.4 1.2.3 148810 100.00 148809 148807 ********************************************************************************************
5-31

Throughput
---> BINARY ITERATION 3, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2232140 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 1.2.4: Total frames transmitted: 2976200 Collecting receive statistics ... 8. Because port 1,2,2 received all the frames from port 1.2.1: Total frames received: 2976200 1,2,1 in the previous iteration (2), the test increased the 1.2.2: Total frames received: 2232140 rate for that pair to halfway between the rate that failed 1.2.3: Total frames received: 2976200 (100%) and the rate that succeeded (50%). 1.2.4: Total frames received: 2976199 Configured Transmit Rates used for iteration 3 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 111607 75.00 111607 111606 1.2.2 1.2.1 148810 100.00 148809 148803 1.2.3 1.2.4 148810 100.00 148809 148803 1.2.4 1.2.3 148810 100.00 148809 148804 ******************************************************************************************** ---> BINARY ITERATION 4, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2604160 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 1.2.4: Total frames transmitted: 2976200 Collecting receive statistics ... 9. For the fourth iteration, the test increased again the rate 1.2.1: Total frames received: 2976200 on port pair 1,2,1 and 1,2,2. As before, the increase (to 1.2.2: Total frames received: 2604160 87.5%) was half the amount between the previous 1.2.3: Total frames received: 2976200 successful rate (75%) and the failed rate (100%). 1.2.4: Total frames received: 2976199 Configured Transmit Rates used for iteration 4 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 130208 87.50 130208 130208 1.2.2 1.2.1 148810 100.00 148809 148802 1.2.3 1.2.4 148810 100.00 148809 148802 1.2.4 1.2.3 148810 100.00 148809 148801 ********************************************************************************************
5-32

Throughput
---> BINARY ITERATION 5, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2793300 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 1.2.4: Total frames transmitted: 2976200 Collecting receive statistics ... 10. For the fifth iteration, port pair 1,2,1 and 1,2,2 received all 1.2.1: Total frames received: 2976200 their frames, so the test increased the rate again. As before, 1.2.2: Total frames received: 2793300 the increase (to 83.85%) was half the amount between the 1.2.3: Total frames received: 2976200 1.2.4: Total frames received: 2976200 previous successful rate (85.5%) and the failed rate (100%). Configured Transmit Rates used for iteration 5 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 139665 93.85 139665 139665 1.2.2 1.2.1 148810 100.00 148809 148798 1.2.3 1.2.4 148810 100.00 148809 148799 1.2.4 1.2.3 148810 100.00 148810 148798 ******************************************************************************************** ---> BINARY ITERATION 6, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2890180 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 11. At the sixth iteration, the test is still trying to find the rate 1.2.4: Total frames transmitted: 2976200 Collecting receive statistics ... at which port pair 1,2,1 and 1,2,2 receive all their frames. 1.2.1: Total frames received: 2976200 As with the previous increases, the increase to 97.11% is 1.2.2: Total frames received: 2890180 half the amount between the previous successful rate 1.2.3: Total frames received: 2976200 (93.85%) and the failed rate (100%). 1.2.4: Total frames received: 2976200 Configured Transmit Rates used for iteration 6 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 144509 97.11 144509 144507 1.2.2 1.2.1 148810 100.00 148809 148558 1.2.3 1.2.4 148810 100.00 148809 148548 1.2.4 1.2.3 148810 100.00 148809 148540 ********************************************************************************************
5-33

Throughput
---> BINARY ITERATION 7, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2941180 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 12. At the seventh iteration, the test is still trying to 1.2.4: Total frames transmitted: 2976200 find the rate at which port 1,2,1 and 1,2,2 receive all Collecting receive statistics ... their frames. Once again, the increase to 98.82% is 1.2.1: Total frames received: 2976200 half the amount between the previous successful rate 1.2.2: Total frames received: 2941180 (97.11%) and the failed rate (100%). 1.2.3: Total frames received: 2976200 1.2.4: Total frames received: 2976200 Configured Transmit Rates used for iteration 7 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 147059 98.82 147058 147059 1.2.2 1.2.1 148810 100.00 148809 148202 1.2.3 1.2.4 148810 100.00 148809 148193 1.2.4 1.2.3 148810 100.00 148809 148163 ******************************************************************************************** ---> BINARY ITERATION 8, framesize: 64, RFC 2544 Throughput Test Resetting Statistics ... Transmitting frames for 20 seconds Done transmitting for 20 seconds... Waiting for Residual frames to settle down for 2 seconds Waited for 1 of 2 seconds Waited for 2 of 2 seconds Collecting transmit statistics ... 1.2.1: Total frames transmitted: 2958580 1.2.2: Total frames transmitted: 2976200 1.2.3: Total frames transmitted: 2976200 1.2.4: Total frames transmitted: 2976200 Collecting receive statistics ... 1.2.1: Total frames received: 2976200 13. At the eighth iteration, port pair 1,2,1 and 1,2,2 1.2.2: Total frames received: 2958580 received all their frames at a rate that was less than 1.2.3: Total frames received: 2976199 1%, below the highest failed rate (100%), so the test 1.2.4: Total frames received: 2976200 ends for that frame size. Configured Transmit Rates used for iteration 8 * Note: DUT Flow Control or Collisions may cause actual TX rate to be lower than Offered Rate TX RX OLoad(fps) %MaxTxRate AvgTxRunRate AvgRxRunRate ******************************************************************************************** 1.2.1 1.2.2 147929 99.41 147928 147929 1.2.2 1.2.1 148810 100.00 148809 148437 1.2.3 1.2.4 148810 100.00 148809 148433 1.2.4 1.2.3 148810 100.00 148809 148414 ******************************************************************************************** Saving results for Trial 1 ...
5-34

Throughput
RFC 2544 Throughput Test - MAC --> Framesize: 64 TX RX TxTput(fps) %TxTput ************************************************* 1.2.1 1.2.2 147929 99.41 1.2.2 1.2.1 148810 100.00 14. Only one frame size was specified for this test, so this 1.2.3 1.2.4 148810 100.00 also ends the test. IxAutomate summarizes the test results. 1.2.4 1.2.3 148810 100.00 ************************************************* AvgRate(fps) = 148589 Tolerance(%) = 0
15. Actual Duration lists the elapsed time of the test, including the entire setup and calculation time. Estimated Run Time, displayed in the Log window at the beginning of the test, is the length of time over which the test configures the transmit ports to transmit.
>>>>>>> End Time: Wednesday, Oct 17, 2001 04:17:45 PM Actual Duration of Test: 00:04:37 seconds
RFC 2544 Throughput Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency.
No. of Trials
Test Parameters Addresses per Rx Port Enable Flow Control Traffic Profile The number of protocol-level addresses to use on each receive port. Enables the Ixia hardware to respond to flow control signals. This allows you to choose how the traffic is sent. You can select one of the following options: Constant Loading Bursty Loading Constant loading is equivalent to transmitting steady traffic. Transmitting bursty traffic means that the traffic is transmitted in successive bursts. Burst Size (# of frames) The number of frames contained in each burst. If you set the value to 1, it means that the traffic is transmitted as constant loading. For a value larger than 1, the test is running with bursty traffic. The minimum value for burst size is 1.
5-35

Throughput
RFC 2544 Throughput Test Run Parameters (Continued) Description The number of frames that could be transmitted during the desired gap period of time, at the specified rate. The minimum value you can set from the graphical user interface is 1. If you are running the test from the command line for a value lower than or equal to 0, the test is aborted with an error message. For example, having the following settings: Frame Size=64; Load Rate=10; Traffic Profile=Bursty Loading; Burst Size (# of frames)=5; Frames per Burst=2; the period of time equivalent with the time for transmitting 2 frames, having the size 64 and the load rate is set to 10% is equal to 115.2 ns.
Staggered Transmit
Sequence Errors Iteration Binary Binary Search
If you check this box, the number of sequence errors in the traffic received from the DUT is calculated.
If you choose this radio button, the binary search parameters display. Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the binary search algorithm searches each port pair separately. A rate change on one port does not affect the others. If you set this field to Linear, the binary search algorithm searches all port pairs together, as a group. A rate change applies to all port pairs.
5-36

Throughput
Table 5-7. Parameter Resolution
RFC 2544 Throughput Test Run Parameters (Continued) Description This parameter is available only when the binary search algorithm is used. The difference between the real rate transmission, expressed as a percentage, in two consecutive iterations, is compared with the resolution value. When the difference between the load rate values in two consecutive iterations is smaller than the specified value for the resolution, the test stops. Init rate is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s). megabits per second (Mbps) gigabits per second (Gbps) kilobytes per second (KBps) megabytes per second (MBps) gigabytes per second (GBps). Note that these rates are the traffic bit rate without the preamble. percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which the frames are transmitted. Use caution when specifying low rates; the test can become less accurate if the frame rate nears 1 f/s.
Init Rate
Loss Tolerance (%)
The percentage of transmitted packets that can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Custom Load
If choosing this radio button, you can set a list of load rate values. The test iterates through them, running the same algorithm for each load rate. The two available parameters display: Load Rate List and Load Rate Unit. Specify the list of load rates to be used. The default list (1 10 50) is recommended when using the hop-by-hop IPv6 header extension in order to measure the DUT performance in terms of resources and not in terms of throughput values.
Load Rate List
Load Rate Unit
Specify the load rate unit: kilobits per second (Kb/s) percentage of the maximum frame rate (%) frames per second (f/s)
5-37

Throughput
RFC 2544 Throughput Test Run Parameters (Continued) Description It allows you to measure the DUT performance of mixed IPv4 and IPv6 environments. If you set the IP/ IPv6 protocol in the Frame Data section, the test creates both IPv4 and IPv6 streams. The test applies the values you select for IPv4 and IPv6 parameters in the IP/IPv6 Ratio parameter field to the Load Rate value, as a percentage of the total traffic sent. For example, if you set IPv4 to 10, IPv6 is set, by default, to 90 (the sum of the two parameters is always 100). If the Load Rate is set to 50%, the test transmits IPv4 traffic at 5% of the load rate (10% of 50 =5) and IPv6 traffic at 45% of the load rate (90% of 50= 45).
IP/IPv6 Ratio
The IPv6 traffic may contain extension headers. For more information about extension headers, see IPv6 Extension Headers on page 5-18. Select the report unit rate to display data in a particular unit. You can select kilobits per second, (kbps) megabits per second (Mbps), gigabits per second (Gbps), kilobytes per second (KBps), megabytes per second (MBps), gigabytes per second (GBps), and frames per second (fps). When you select any unit other than megabits per second (Mbps), an additional column is displayed in iteration.csv, results.csv, and Aggregateresults.csv displaying the data in the selected unit.
Report Unit Rate
5-38

Throughput
RFC 2544 Throughput Test Run Parameters (Continued) Description
Pass Criteria Pass Criteria If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass/fail criteria are applied to the Rx rate. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kbps) megabits per second (Mbps), gigabits per second (Gbps), kilobytes per second (KBps), megabytes per second (MBps), gigabytes per second (GBps), frames per second (fps). Note that this is the traffic bit rate without the preamble. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
Ports: See Setting Up Ports on page 3-7. Protocol: See Configuring IP, IPX, and MAC Addresses on page 3-18. Notes: 1. If you set the Protocol to MAC protocol, the Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device. 2. For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports.
5-39

Troubleshooting the RFC 2544 Tests
If you select Increment Across Ports, the TCP/UDP port number is incremented for each Tx-Rx port pair used in the test configuration. If you select the Increment on Same Port, the TCP/UDP port number is incremented for each address emulated for each Tx-Rx port pair used in the test configuration.
Assigns VLAN IDs on page 3-43. For information about double VLAN tagging see Stacked VLAN (Q in Q) on page 5-2.

Some causes of unexpected results of the RFC 2455 tests are: Management Not Turned Off on page 5-40. Intermittent Bugs in DUT Firmware on page 5-40. DUT Design / Performance Limitations on page 5-41. Collisions During Bidirectional Tests on page 5-41. Auto-Negotiation Placing Links in Bidirectional Mode on page 5-41. Spanning Tree on page 5-42. Error Message Error -- 0 packets received on port x.x.x on page 5-42. Error Message Error -- No ARPs received on page 5-42. Link Down on page 5-42.
Management Not Turned Off
If management is turned on, it adversely affects the test results. Most switches are programmed to give higher priority to generating management frames than to forwarding traffic. If you run the test with management turned on, the DUT attempts to behave as it would in a real networkby devoting some processing time to its management features to maintain itself and its neighbors. Running tests on DUTs with intermittent flaws can also create some unusual results. For example, suppose that the DUT has a flaw that only occurs every 30 seconds (s). A script that transmits for 20 seconds (s) may not uncover the flaw, but a script that transmits for 30 seconds (s) does, because the flaw occurs during the time the script is transmitting.
Intermittent Bugs in DUT Firmware
5-40

If the flaw is mild or well-handled by the DUTs error-handling routines, it may only result in a few lost frames, and the test binary searches to find a new rate. But if the flaw occurs while the test is transmitting and is serious enough to make some ports go down, the test has no idea what is going on. As some ports come up and others go down, the test tries to recalculate new rates, but if they alternately go up and down, the test results diverge, making it impossible for the test to find the real rate.
DUT Design / Performance Limitations
Some DUTs have a firmware component that cannot cope with a full load on all ports simultaneously. If you drop one pair of ports, the remainder may be able to transmit at the expected throughput. If you add the dropped pair back to the test mix and transmit to all ports again, the throughput on all ports may go down again. At any given time, one of the pairs is dropping frames, but it is impossible to tell which one. The tests binary search is unable to find the true rate of a port because it alternately works and then does not work at a given rate. The solution to this is to lock the ports together so that the binary search increases or decreases all rates on all ports together, instead of on a per-port basis. To do this, set the Binary Search field to Linear. For example, if you set Binary Search to Linear and the test cannot transmit at 100 percent, it drops all ports to 50 percent, and then retries. In many cases, this is a more accurate way of finding a DUTs total performance, rather than its per-port performance.
Collisions During Bidirectional Tests
Although there is nothing in the software that stops you from configuring a halfduplex bidirectional test, you should expect many collisions when a pair of ports is transmitting at 100 percent. An indication of this is the transmit duration LEDs; they are on for about one minute for a test that only needs to transmit for 20 seconds. The results for this test are likely to be very poor, because no matter how low the transmit rate, at least one frame is likely to be dropped, to the point where the test finally gives up when the rate drops below 100 f/s. This can be a problem for DSL testing because of DSL large frame sizes.
Auto-Negotiation Placing Links in Bidirectional Mode
Another example of half-duplex bidirectional testing involves auto-negotiation. When a mismatch occurs during negotiation on a Fast Ethernet link, the link falls to the lowest common denominator. However, auto-negotiation can detect link speed, but it cannot detect duplex mode, so it defaults to half-duplex. For example, if you have auto-negotiate turned off on the DUT and turned on at the Ixia port, regardless of the DUT ports capabilities, the link is forced to the lowest common denominator, that is, 100Mb half-duplex. A test run over this link would show very unexpected results, the LEDs on the Ixia and DUT would take a long time to show SYNC, and the test would likely fail.
5-41

Spanning Tree
Another example of mis-configuration involves having both spanning tree protocol and auto-negotiation turned on. When the test prepares to run over an auto-negotiated link, it sets parameters such as port speed, mode, and addresses with the DUT port, then it takes the link down and brings it back up in the negotiated configuration. If spanning tree is turned on, it forces all ports into a blocking state for 30 seconds (s). The links then come up, but no port is able to forward while the links forward BPDUs to each other. The test is not aware that spanning tree is enabled; it sees the link come up and immediately tries to transmit. Because no frames are received, it then drops into its binary search routine, and tries again. Usually, the test ends before the blocking state does, and the test fails with zero frames received. To check if spanning tree is enabled, use IxExplorer.
Error Message Error -- 0 packets received on port x.x.x
If a receive port receives no frames at all from a DUT, even though the links are up, make sure that: the DUT ports and the Ixia ports are on the same VLAN IP forwarding is enabled on the DUT DUT is not adding 802.1 queue tags
Error Message Error -- No ARPs received
Lack of ARP response from a DUT during Layer 3 testing is often caused by mismatched IP addresses. Make sure that you have entered the correct DUT port addresses in the Gateway IP Address field. When working with Ethernet devices, the calculated maximum throughput rate may not show 100% even when a device fully complies with the IEEE 802.3 and 802.3z standards. This is due to the tolerance allowed within these standards and to the accuracy of the Ixia port clocks. An application note entitled Ethernet Performance Measurement available on Ixias Web site (http://www.ixiacom.com) describes this issue in detail.
Link Down
A link down error can be caused by: missing, disconnected, or defective cables DUT powered off mismatched auto negotiation state improperly mapped ports (incorrect port range)
5-42
Chapter 6:
RFC 2889 Test Suite
This chapter describes the tests created in accordance with RFC 2889 under the following topics: Run Parameters on page 6-1. Setting Up the Tests on page 6-5. Address Cache Size on page 6-6. Address Rate on page 6-8. Back-Pressure on page 6-10. Broadcast Rate on page 6-13. Head of Line Blocking on page 6-14. Frame Error Filtering on page 6-16. Fully-Meshed on page 6-17. Many-to-Many Mesh on page 6-22. Many-to-One Throughput on page 6-25. One-to-Many Throughput on page 6-27. Partially-Meshed on page 6-29.
Run Parameters
The Run parameters used in these tests are described in Table 6-1.
Table 6-1. Parameter Duration RFC 2889 Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames to transmit. The default value is 30 seconds (s).
Test Parameters
6-1
RFC 2889 Test Suite

Run Parameters
Table 6-1. Parameter No. of Trials
RFC 2889 Test Run Parameters (Continued) Description The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. The number of protocol level addresses to use on each receive port If you enable this check box, multiple addresses per each Tx port can be set. The number of addresses set for each Tx port is the value configured for the Addresses per Rx Port parameter. This should coincide with the address table aging parameter in the DUT. The address table needs to be aged out between each retry for a new table size in order to ensure a fresh, empty table. Setting the age out parameter to the minimum value used by the DUT drastically speeds up this test. When streams are applied to a number of ports at a time, the start time between ports is staggered by approximately 27 ms. Causes jitter to be calculated as well as throughput. Causes latency to be calculated as well. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. This option is available if the IxOS version used is at least 5.10.
Addresses per Rx Port Enable Multiple Addresses per Tx Port Age
Staggered Transmit Calculate Jitter Calculate Latency Calibrate Latency
Burst Size
The number of packets to send in a burst. As defined in RFC2889, the burst size value is an integer between 1 and 930. A burst size of 1 means that the test is using a constant loading traffic profile.
Mesh Type
See RFC 2889. Choose one of following: Round Robin Peak Loading
MOL (%)
Maximum Offered Load. The tests that include this parameter use it to create congestion on an interface. Specify this parameter as a percentage of the maximum theoretical frame rate of the port on which congestion is to occur. The number of frames to send per trial The number of iterations from the Max Rate
No. of Frames No. of Iterations
6-2
RFC 2889 Test Suite

Run Parameters
RFC 2889 Test Run Parameters (Continued) Description Amount of congestion desired on the receive port Specify Overload as a percentage of the maximum line rate of the Ixia receive port connected to the congested interface. A value of 100% for Overload is equivalent to the maximum line rate for the receive port. Anything exceeding 100% overload creates congestion. For example: Four 100 Mb/s ports transmit at half-duplex to one 100 Mb/s half-duplex receive port. The default 200% overload results in the four transmit ports transmitting at 50% line rate. This results in 200 Mb/s arriving on the 100 Mb/s receive port, thus congesting it.
Overload (%)
Detailed Results
If you check this box, the detailed results are available when the test run ends. For example, port 1 is the transmit port and the receiving ports are port 2, port 3, and port 4. If this option is enabled, then for each transmit-receive peer, detailed information is available.
Table Size
Should be set to the total size of the address table of the DUT or higher. The test begins at half the specified table size, then proceeds to perform a binary search until the DUT table size is determined. The table size is determined based on the maximum number of learned addresses that do not drop or flood frames to other ports. The time to wait, in seconds (s), after the transmission starts, to allow the receive frames to settle down. If you check this box, IxAutomate creates a separate results file that contains data only about those port pairs that experienced either frame loss or sequence errors. The port pair error result file is saved to the same path and file name as the Result File, with -error inserted in the name. For example, if the Result File is fullyMeshed.result, the port pair error file is named fullyMeshederror.result. If you use MAC protocol, you cannot use more than 254 ports if you want IxAutomate to generate a port pair error detail report.
Wait Residual Port Pair Error Details (Result Display Options)
6-3
RFC 2889 Test Suite

Run Parameters
RFC 2889 Test Run Parameters (Continued) Description If you check this box, the test includes the following types of sequence errors in the results: Small Sequence Errors: Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by the software) and not negative, or when the expected sequence number is equal to the previous sequence number. Big Sequence Errors: Number of packets received with large sequence errors A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. Reverse Sequence Errors: Number of packets received with reverse sequence errors A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. Sequence Errors: Combined total of packets with sequence errors of all types To enable sequence error checking: your test must not use more than 254 ports the ports that you use must support the Wide Packet Groups feature in the Receive mode. For information about port features, see the Ixia Hardware Guide.
Sequence Errors (Result Display Options)
Iteration Binary Search Min Rate Enable Flow Control Determines whether the tests binary search searches all ports (Linear) or each port individually (Per Port). The minimum rate used for the binary search algorithm. Enables the Ixia hardware to respond to flow control signals. This option is available only for the following tests: Back-Pressure Many-to-One Throughput One-to-Many Throughput Increment, Increment (%) Initial Rate (%) The increment (+value) or decrement (-value) as a percentage to apply to the transmission rate. The initial rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate of the port. The percentage of total sent packets to allow to be lost before declaring packet loss.
Loss Tolerance (%)
6-4
RFC 2889 Test Suite

Setting Up the Tests
Table 6-1. Parameter Resolution
RFC 2889 Test Run Parameters (Continued) Description This parameter is available only when the binary search algorithm is used. The difference between the real rate transmission in two consecutive iterations, expressed as a percentage, is compared with the resolution value. When the difference is smaller than the value specified for the resolution, the test stops.
Init Rate (%)
The initial rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate of the port.

Most of the RFC 2889 test parameters are common to all the tests and work the same way on all of them. The description of each test includes a description of the parameters that are unique for that test. The common run parameters for the RFC 2889 tests are described in Run Parameters on page 6-1. The other parameters are described as follows: Protocols: All multicast tests use IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Additionally, when choosing the IP or IPv6 protocols, you can select: The encapsulation protocol over IP: UDP, TCP, or None. The TCP/UDP port used to send traffic: Source Port The TCP/UDP port used as destination: Destination Port If you check the Increment Port option, the TCP/UDP port number is incremented for each Tx-Rx port pair used in the test configuration. This means that the TCP/UDP port number increments per stream. Frame Sizes: All multicast tests allow you to select and test multiple frame sizes. For information about frame sizes, see Choosing Frame Sizes on page 3-45. Learning Frames: See Configuring Learning Frames on page 3-23 Traffic Mapping: Most of the tests use one-to-many traffic maps, as described in Setting Up the Traffic Map on page 3-11. VLANs: For the parameters common for most of the tests in IxAutomate, see Setting the VLAN Parameters on page 3-42 and How IxAutomate Assigns VLAN IDs on page 3-43.
6-5
RFC 2889 Test Suite

Address Cache Size
NOTES: 1. For better results, when using Address Rate and Address Cache scripts, it is recommended to run the Address Cache Size test first, then the Address Rate test. 2. For the Address Cache Size and the Address Rate tests, you can enable or disable link drop on the ports (Port Config) between test iterations and configure the length of the link drop in milliseconds.
Address Cache Size

This section covers the following topics: Overview on page 6-6. Supported Protocols on page 6-7. Test Setup: Run Parameters on page 6-7. Pass/Fail Criteria on page 6-8.
Overview
This test determines the maximum MAC address table for each port or for an entire switch. It uses a binary search to find the size of the address table, beginning at half the size of the initial user-specified table size. Learn frames are transmitted between each iteration, then generic frames are transmitted at a userspecified frame rate to see if the DUT has properly learned all the addresses. If no frame loss and no flooding is detected, the address table size is increased and the test is repeated in a binary fashion until the address table size is determined. The binary search algorithm ends when the difference between the best iteration and the searched-for maximum iteration is less than or equal to the number of addresses set for the Resolution parameter. If there is one address table for the entire switch, then the test needs to be run only on one transmit port to all receive ports on the switch. If there is one address table per port, then this test should be run for each port. The port mapping used is one-to-many, with three ports minimum. Unidirectional traffic is used in this test. The test results show the MAC address size obtained for each frame size for an entire device or on a per port basis. Before you configure this script, you need to establish a few aspects regarding the switch: 1. Filter DataBase table (FDB) entry clearing: A layer 2 switch typically retains the entries in the filter database table as long as the addresses are seen in data packets. If the data packets stop, the addresses stay in the table until a timer expires (the FDB aging timer), and then they are deleted from the table to free up memory. Most switches default to an aging timer value of 300 seconds (5 minutes). Since the script requires a blank (completely empty) FDB at the beginning of each iteration, the Age parameter in the script must be set to a value greater than this to get proper results. This most likely extends the dura-
6-6
RFC 2889 Test Suite

Address Cache Size
tion of the test to several hours or more. However, many switches clear the FDB entries immediately if the port link is dropped by cable disconnect. Our script drops the link-down, after which you can set the Age parameter to a low value (such as 5 seconds), so the test finishes much faster. 2. Initial table size: The script performs a binary search to determine the FDB size. The Table Size parameter needs to be set to a value that is guaranteed to be larger than the actual FDB table size in the switch in order for the binary search to be successful. You can either be given advance notice about how large the FDB should be (for example, from a data sheet for the device), or make assumptions based on the size of the device (for example an 8-port switch probably has something less than 2048 entries), or simply use a very large size at first, to get an idea, then run the test again with a better approximation. 3. Learn Frame Rate: The Learning Frames parameters in the script should be adjusted so that the duration of the learning frames burst does not exceed the FDB size of the switch. The default values are probably not going to be adequate. For example, for a simple 8-port switch, these parameters may be set as follows: Table Size = 5000 Number of Learning Frames =1 (default 10) Rate (f/s) = 10000 (default 100). This results in a learning frame burst duration of 0.5 seconds (s). The default values result in a learning frame burst duration of 500 s, which exceeds the standard FDB aging timer value. 4. Transmit Frame Rate: The Init Rate (%) parameter should be set to a comfortable forwarding rate for the switch. The Number of Frames parameter can be set to 1, unless you like to send duplicate frames.
Supported Protocols
The protocols supported by this test are:

Supported Protocols Features Required on Ports Transmit port MAC, VLANs Packet Streams mode Receive port Capture mode
For more information about the common run parameters, see Run Parameters on page 6-1. For information about the common settings for the RFC 2889 tests, see Setting Up the Tests on page 6-5.
6-7
RFC 2889 Test Suite

Address Rate
NOTE: For the Address Cache Size and the Address Rate tests, you can enable or disable link drop on the ports (Port Config) between test iterations and configure the length of the link drop in milliseconds.
For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1. For information about other tests in this family, see RFC 2889 Test Suite on page 6-1.
Pass/Fail Criteria
Table 6-2 lists the pass/fail criteria available for this test:
Table 6-2. Parameter Pass Criteria Address Cache Size Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Number of addresses that the DUT should be able to store in its address cache Pass: The number of addresses stored by the DUT is equal to or greater than the number you entered. Fail: The number of addresses stored by the DUT is less than the number you entered.
Cache Table Size
Address Rate
Overview
This test determines the maximum MAC address learning rate of a switch device. In each trial, frames with multiple addresses based on the specified initial table size are transmitted at a user-specified frame rate. The number of frames received on each receive port is counted and the receive rate calculated. The rates are compared and a binary search algorithm determines the rate at which experienced frame loss is less than of equal to the number of frames per second set for the Resolution parameter. This test uses the one-to-many mapping, but only one port is used for transmission at a time; received address packets should appear on the specified receive ports. Unidirectional traffic is transmitted for this test. The test results show the MAC address learning rate in frames per second (f/s).
6-8
RFC 2889 Test Suite

Address Rate
NOTE: According to RFC 2889, address learning rate must be tested using at least three ports. However, IxAutomate allows you to configure and run the Address Rate test with only two ports. If you want to run this test in conformance with the RFC, use at least three ports.
The subsequent paragraph provides you with some guidelines on setting Test Setup parameters for the Address Rate script to secure better results: Run Parameters: No. of Trials = 1; No. of Frames = 1; Init Rate (%) = 50; Table Size = slightly less than the current table size in the DUT; Wait Residual = 5. Frame Size: Frame Size = 64 only. Learning Frames: Frequency = On Iteration; No. of Frames = 1; Frame Size = 64.
Supported Protocols

When choosing the MAC protocol: The Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device.
6-9
RFC 2889 Test Suite

Back-Pressure
NOTES: For the Address Cache Size and the Address Rate tests, you can enable or disable link drop on the ports (Port Config) between test iterations and configure the length of the link drop in milliseconds.
Pass/Fail Criteria
Table 6-3. Parameter Pass Criteria Address Rate Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to absorb addresses. Specify this parameter in terms of frames per second (f/s). Pass: The DUT absorbed addresses at a rate equal to or greater than the rate you entered. Fail: The DUT absorbed addresses at a rate less than the rate you entered.
Address Learning Rate
Back-Pressure
This section covers the following topics: Overview on page 6-10. Supported Protocols on page 6-11. Test Setup: Run Parameters on page 6-11. Test Setup: Other Parameters on page 6-11. Pass/Fail Criteria on page 6-11.
Overview
This test looks for congestion control back-pressure exerted when multiple ports are transmitting to a single port in order to overload the port. The specified stream configuration begins the transmission. If the ports are set to half-duplex and back-pressure is exerted, there should be no frame loss and collisions should be detected. If the ports are set to full-duplex and flow control is enabled, flow control frames should be detected. If back-pressure is not exerted, then the total transmitted frames do not equal the total number of received frames. A many-toone port mapping is used with a three-port minimum. Unidirectional traffic is transmitted for this test.
6-10
RFC 2889 Test Suite

Back-Pressure
The results of the test show the number of received frames, number of collision frames, and the percentage of lost frames obtained for each frame size.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port MAC, IP, IPv6, IPX, VLANs Packet Streams mode Receive port Capture mode
For more information about the common run parameters, see Run Parameters on page 6-1. For information about the common settings for the RFC 2889 tests, see Setting Up the Tests on page 6-5. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1. For information about other tests in this family, see RFC 2889 Test Suite on page 6-1.
Protocol parameters: See Configuring IP, IPX, and MAC Addresses on page 3-18.
NOTE: For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses and VLAN IDs (if the 802.1q Tag option is enabled) to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option helps with better address distribution for different tests with different excluded ports.
Pass/Fail Criteria
6-11
RFC 2889 Test Suite

Back-Pressure
Back Pressure Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. The test considers frames retransmitted due to collisions when calculating the percentage of lost frames. Pass: The percentage of frames lost by the DUT was less than or equal to the percentage you entered. Fail: The percentage of frames lost by the DUT was greater than the percentage you entered.
Pass Criteria
% Loss
Max Collisions
Maximum number of frames lost due to collisions. The test considers frames retransmitted due to collisions when calculating the percentage of frames lost. For example, if % Loss is 100 and Max Collisions is 1: If the number of collisions is 1, the test ignores the frames retransmitted as a result of the collision when calculating the loss percentage. If 2 or more collisions occur, the test ignores the first collision and includes the remaining retransmitted frames in the loss percentage calculation.
6-12
RFC 2889 Test Suite

Broadcast Rate
Broadcast Rate
Overview
This test determines the maximum rate at which the DUT receives and forwards broadcast frames without any frame loss. Frames are initially sent at a user-specified rate, generally the maximum theoretical rate based on the speed of the port. A binary search algorithm is used to obtain a rate at which the DUT does not lose frames within an acceptable rate window. This window is the rate within one inter-frame gap of the initial rate. If the test performs the first iteration and no frames are received, then a second iteration is performed; after that, if no frames are received, the test stops; otherwise, the binary search algorithm continues. The latency is also calculated in this test. This test is configured with a one-tomany traffic mapping and a three port minimum, but only one port is used for transmission at a time; received broadcast packets should appear on the specified receive ports. Unidirectional traffic is transmitted for this test. The test results show the throughput rates obtained for each frame size.
Supported Protocols

6-13
RFC 2889 Test Suite

Head of Line Blocking
Pass/Fail Criteria
Table 6-5. Parameter Pass Criteria Broadcast Rate Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass/fail criteria are applied to the Rx rate. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate

Overview
This test looks for added delay on an uncongested output interface whenever frames are received from an input interface that is also attempting to forward frames to a congested output interface. If the ports are set to half-duplex, collisions should be detected on the transmitting interface. If the ports are set to fullduplex and flow control is enabled, flow control frames should be detected. A fully-meshed port mapping with two ports is used. Multiple addresses per receive
6-14
RFC 2889 Test Suite

ports are supported. A and B transmit to a third port, C, to form the congested interface, while port A also transmits to port D as an uncongested interface. The test results show the number of received frames, number of collision frames, and the percentage of lost frames obtained for each frame size.
Supported Protocols

Pass/Fail Criteria
Table 6-6. Parameter Enable Pass Criteria Head of Line Blocking Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The test detected no head-of-line blocking for any frame size. Fail: The test detected head-of-line blocking for at least one frame size.
6-15
RFC 2889 Test Suite

Frame Error Filtering
Frame Error Filtering

Overview
This test determines whether the DUT correctly filters frames with certain types of errors such as undersized frames, oversize frames, CRC errors, fragments, alignment errors, and dribble errors. This test is configured with a one-to-many traffic mapping. The test results show the type of error transmitted, the number of transmit frames, and the number of errored frames obtained for each frame size.
NOTE: Only the LM100TX and LM1000T5 cards can generate frames containing alignment and dribble errors.
Supported Protocols

6-16
RFC 2889 Test Suite

Fully-Meshed
Pass/Fail Criteria
Table 6-7. Parameter Enable Pass Criteria Frame Error Filtering Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The test detected no frames with errors for any frame size. Fail: The test detected at least one frame that contained an error.
Fully-Meshed
This section covers the following topics: Overview on page 6-17. Supported Protocols on page 6-18. Test Setup: Run Parameters on page 6-19. Test Setup: Other Parameters on page 6-19. Pass/Fail Criteria on page 6-19. Using the Fully-Meshed Test with 255 or More Ports and Four or More Addresses per Port on page 6-20.
Overview
The Fully-Meshed Throughput Test is used to determine the total number of frames that the DUT can handle when it receives frames on all its ports. For this test, all ports transmit and receive traffic at a specified transmission rate such that each one of the interfaces on the DUT transmits frames and receives frames addressed to/from all of the other interfaces under test. In addition, each port in the test sends frames to all the other ports in an evenly-distributed, round-robin type fashion. A binary, linear, or fixed search type can be selected to determine the maximum no drop rate. If you enable the Calibrate Latency option, the intrinsic latency of the port is subtracted from the measured latency values. (IMPORTANT: The Calibrate Latency option is available only if the IxOS version used is at least 5.10.) If you enable the Uniform Media check box, the information for all the ports with identical specifications used in a particular test is taken only from one port, speeding up the process. For more information about the run parameters, see Run Parameters on page 6-1. The Dual Mesh option is now available for the Map parameter. It enables you to configure two Traffic Maps. Each traffic map has a separate set of ports. Each
6-17
RFC 2889 Test Suite

Fully-Meshed
port in one map sends frames to all the other ports in the same map and no traffic is sent between maps. The Send Fully Meshed parameter is available only when the MAC protocol is selected. If you enable this option in the Learning Frames widget, the Ixia chassis transmits learning frames from each address configured per each Rx Port to each address configured per each Tx Port. If you do not enable it, the Ixia chassis transmits learning frames from each address configured per Rx Port to only one of the Tx Ports. When the Fixed Search Iteration option is enabled, the test executes one iteration with the specified Load Rate. When choosing the MAC protocol: You can set the initial MAC address in the First MAC Address parameter field, as well as the increment step in the Increment By parameter field. The Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device.
IMPORTANT: For the MAC or IPv6 protocol, the Increment By parameter should include four adjacent octets. Otherwise, the incrementation cannot be performed. Table 6-8 shows how each port transmits frames to all the other ports in the test. In this example, there are six ports with one address per port:
Table 6-8. Fully-Meshed Port Usage Destination Ports (in order of transmission) 2 3 4 5 6 2... 3 4 5 6 1 3... 4 5 6 1 2 4... 5 6 1 2 3 5... 6 1 2 3 4 6... 1 2 3 4 5 1...
Source Port Port #1 Port #2 Port #3 Port #4 Port #5 Port #6
The results of the test show the total number of frames transmitted from all the ports and the total number of frames received on all the ports, and the percentage of lost frames obtained for each frame size. An option is provided in this test to calculate the jitter or the average latency along with calculating the frame loss.
Supported Protocols
6-18
RFC 2889 Test Suite

Fully-Meshed
Supported Protocols
Features Required on Ports Transmit port Receive port Packet Group mode
MAC, IP, IPv6, IPX, VLANs
Packet Flow mode
If you select a port for this test that does not support these features, IxAutomate drops that port from the ports list. To determine the features available on your ports, see the Ixia Hardware Guide.
Note: For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses and VLAN IDs (if the 802.1q Tag option is enabled) to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports.
Pass/Fail Criteria
6-19
RFC 2889 Test Suite

Fully-Meshed
Fully-Meshed Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Pass Criteria
% Frame Loss
Latency
Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Sequence Errors
Number of sequence errors in the traffic received from the DUT. Pass: The number of sequence errors in the traffic received from the DUT was less than or equal to the number you entered. Fail: The number of sequence errors in the traffic received from the DUT exceeded the number you entered.
Using the FullyMeshed Test with 255 or More Ports and Four or More Addresses per Port
If you use the Fully-Meshed test with large (255 or more) port counts and four or more addresses on each port, there are certain differences in the way the test functions are comparable to configurations with fewer ports and addresses per port. This section describes these differences: Port Types on page 6-21.
6-20
RFC 2889 Test Suite

Fully-Meshed
Transmission Sequence on page 6-21. Protocol Considerations on page 6-21. IP Address Configuration on page 6-22. Unused Destination Addresses on page 6-22.
Port Types
In a large port count test, all the ports must be of the same type. Otherwise, the test aborts.
Transmission Sequence
In a large port count test, the source ports transmit packets in groups of four addresses per port. If there are not enough addresses to complete a group of four, the test transmits the remaining addresses in bursts of four packets. For example, if the Addresses per Rx port is 6, the transmit sequence is as described in Table 610.
Table 6-10. Addresses 1 through 4 5 through 6 Transmission Sequence for Large Port Count Test (5 ports, 10 Rx addresses per port) Transmit Sequence 1 - 2 - 3 -4 5-5-5-5 6-6-6-6
Protocol Considerations
If you use the IP protocol, the maximum value you can enter for the Addresses per Rx port is 508. If you use the MAC protocol, the total number of supported MAC addresses is 114688. When using both automatic and dual-mesh traffic map, the VLANs parameters may be used to enable the outer VLAN tag (Enable 802.1q Tag) and the inner VLAN tag (Enable stacked VLAN (Q in Q)): For the outer VLAN, you can set the First VLAN ID, the Increment VLAN ID (these are available in the Traffic Setup window, Frame Data section); For the stacked VLAN, you can define the First Inner VLAN ID and the Increment Inner VLAN ID (these are available in the Traffic Setup window, Frame Data section).
If the Enable stacked VLAN (Q in Q) option is checked, the Send Mac Only option from the Learning Frames section is automatically activated.
6-21
RFC 2889 Test Suite

Many-to-Many Mesh
For example, the double VLAN tagging can be useful for Internet Service Providers, allowing them to use VLANs internally while handling traffic from clients that is already VLAN tagged.
IP Address Configuration
The host portion of the First Port Source Address must be divisible by four (leastsignificant two bits set to 0), and the fourth byte cannot be 0 or 252. As a result, the lowest value you can use for this parameter is 4. The host portion of the Gateway / DUT address can be anything except all ones or all zeroes (for a class C address, 0 and 255) and should not match a destination address configured on the attached Ixia port. As the test does not create packets containing destination addresses in which the fourth byte is 0-3 or 252-255, you can safely use these addresses for the DUT. The network IP addresses of the DUT ports must be incremented by 4. For example, in a configuration using class C addresses, if the first DUT port has the address 198.18.0.1, the next port should have the address 198.18.4.1, then the next should have 198.18.8.1, and so on.
Unused Destination Addresses

The test does not create packets with destination addresses in which the last byte is 0-3 or 252-255. For example, if you set the First Port Source Address to 198.18.4.248, and Addresses per Rx port to 8, the test generates the following addresses:
198.18.4.248 198.18.4.249 198.18.4.250 198.18.4.251 198.18.5.4 198.18.5.5 198.18.5.6 198.18.5.7
Many-to-Many Mesh
Overview
This test transmits and receives traffic from all ports of all cards and chassis in the configuration. It determines the frame loss out of the total number of frames
6-22
RFC 2889 Test Suite

Many-to-Many Mesh
transmitted from all the ports and the total number of frames received on all the ports. It is assumed that the number of ports that a particular port is receiving from and transmitting to is the same; that is, every transmit port must receive from all those ports. If the mapping is not configured in this way, inaccurate results can be expected. The transmit rate is adjusted based on two parameters: (1) the minimum rate that the receive ports can handle must be used on all transmit ports, and (2) the rate must be half the maximum rate if the transmit port is set to half-duplex mode. This test is configured with a many-to-many traffic mapping. An option is provided in this test to calculate the jitter or the average latency along with the frame loss. If you set the Burst Size to less than 4, the test may not be able to calculate the latency on some interfaces. The Calibrate Latency option is available when calculating the latency. If you enable this option, the intrinsic latency of the port is subtracted from the measured latency values. (IMPORTANT: The Calibrate Latency option is available only if the IxOS version used is at least 5.10.) There are two types of many-to-many mesh tests available: round-robin and peak-load. The round-robin mesh test transmits an even distribution of frames to all ports involved in the test; the peak-load algorithm uses a round-robin type approach combined with overloading various ports throughout the testing period. Over time, the overall peak-load result is very similar to the round-robin approach; however, the peak-load approach stresses the DUT buffering capability. For example, by using the peak-load algorithm on an eight-port switch, frames are transmitted as shown in Figure 6-1, while the round-robin algorithm on an eight-port switch is shown in Figure 6-2 on page 6-24.
Tx Port Rx Ports 1 2 3 4 5 6 7 8 Figure 6-1. 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 1 1 1 3 4 5 6 7 8 3 4 5 6 7 8 3 4 5 6 7 8 1 2 1 2 1 2 4 5 6 7 8 4 5 6 7 8 4 5 6 7 8 1 2 3 1 2 3 1 2 3 5 6 7 8 5 6 7 8 5 6 7 8 1 2 3 4 1 2 3 4 1 2 3 4 6 7 8 6 7 8 6 7 8 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 7 8 7 8 7 8 1 2 3 4 5 6 1 2 3 4 5 6 1 2 3 4 5 6 8 8 8 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 Peak Load Port Usage
Tx Port Rx Ports 1 2 2 3 4 5 6 7 8 2 3 4 5 6 7 8 2 3 4 5 6 7 8 3 4 5 6 7 8 1 3 4 5 6 7 8 1 3 4 5 6 7 8 1
6-23
RFC 2889 Test Suite

Many-to-Many Mesh
Tx Port Rx Ports 3 4 5 6 7 8 Figure 6-2. 4 5 6 7 8 1 2 4 5 6 7 8 1 2 4 5 6 7 8 1 2 5 6 7 8 1 2 3 5 6 7 8 1 2 3 5 6 7 8 1 2 3 6 7 8 1 2 3 4 6 7 8 1 2 3 6 7 8 4 1 2 3 4 7 8 1 2 3 4 5 7 8 1 2 3 4 5 7 8 1 2 3 4 5 8 1 2 3 4 5 6 8 1 2 3 4 5 6 8 1 2 3 4 5 6 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 Round Robin Port Usage
Supported Protocols

Supported Protocols Features Required on Ports Transmit port MAC, IP, IPv6, IPX, VLANs Packet Flow mode Receive port Capture mode
Pass/Fail Criteria
6-24
RFC 2889 Test Suite

Many-to-One Throughput
Many-to-Many Mesh Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Pass Criteria
% Frame Loss
Overview
This test determines the maximum rate at which the DUT receives and forwards frames from many interfaces (that is, multiple 1GE) to one interface (that is, one 10 GE) without any frame loss. A binary or a linear search algorithm can be used to obtain a rate at which the DUT does not lose frames within an acceptable rate window. This window is the rate within one inter-frame gap of the initial transmit rate. In this case, the window is actually the sum of all the windows of the transmit ports. This test is configured with a many-to-one traffic mapping. Multiple port groups can be run at a time. Multiple addresses per receive ports are supported. Bidirectional traffic is generated and analyzed. Based on the burst size value, the traffic profile can be constant (burst size of 1) or bursty. The test results show the maximum throughput rate obtained for each frame size. The protocols supported by this test are:
Supported Protocols
6-25
RFC 2889 Test Suite

Supported Protocols
Features Required on Ports Transmit port Receive port Capture mode
MAC, IP, IPv6, IPX, VLANs
Packet Streams mode
Pass/Fail Criteria
6-26
RFC 2889 Test Suite

One-to-Many Throughput
Many-to-One Throughput Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass/fail criteria are applied to the Rx rate. Depending on the selected Search Type: for Linear iteration - the rate at which the DUT should be able to transmit the received traffic at the specified rate in the test. for Binary iteration - the rate at which the DUT should be able to transmit and receive in the specified tolerance. The Load Rate is expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Pass Criteria
Load Rate
Overview
This test determines the maximum rate at which the DUT receives and forwards frames from one interface (that is, one 10GE) to many interfaces (that is, 1GE) without any frame loss. A binary or a linear search algorithm can be used to obtain a rate at which the DUT loses frames within an acceptable rate window. This window is the rate within one inter-frame gap of the initial transmit rate.
6-27
RFC 2889 Test Suite

This test is configured with a one-to-many traffic mapping. Multiple port groups can be run at a time. Multiple addresses per receive ports are supported. Bidirectional traffic is generated and analyzed. Based on the burst size value, the traffic profile can be constant (burst size of 1) or bursty. The test results show the maximum throughput rates obtained for each frame size.
Supported Protocols

Pass/Fail Criteria
6-28
RFC 2889 Test Suite

Partially-Meshed
One-to-Many Throughput Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass/fail criteria are applied to the Rx rate. Depending on the selected Search Type: for Linear iteration - the rate at which the DUT should be able to transmit the received traffic at the specified rate in the test. for Binary iteration - the rate at which the DUT should be able to transmit and receive in the specified tolerance. The Load Rate is expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Pass Criteria
Load Rate
Partially-Meshed
Overview
This test is used to determine the maximum throughput of the DUT while transmitting and receiving traffic on multiple ports. Bidirectional traffic is generated and analyzed. Based on the burst size value, the traffic profile can be constant (burst size of 1) or bursty. A binary or a linear search for the maximum no drop rate can be configured using this test.
6-29
RFC 2889 Test Suite

Partially-Meshed
The test results show the maximum throughput per frame size, the percentage of lost frames and the sequence errors.
NOTE: The Partially-Meshed test uses Protocol Server in Packet Group mode, if the ports support this feature. If you run the test on a port that does not support Protocol Server, it sets the port to the Capture mode to send the ARP request using streams. While the port is changing to a corresponding receive mode, the link may go down, causing some ARP requests to fail.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port MAC, IP, IPv6, IPX, VLANs Packet Flow mode Receive port Capture mode
NOTES: 1. For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option becomes available. It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option helps with better address distribution for different tests with different excluded ports. 2. In order to obtain bidirectional traffic in the Manual Port Map window, select Bidirectional before selecting any port pairs for the map. This way, when a source-destination port pair is added to the Configured Maps area, the port pair in the inverse direction is added as well (Figure 6-3). Example: With Bidirectional selected, if pair 1.1.1 - 1.1.2 is added to the Configured Maps, then 1.1.2 - 1.1.1 is added also.
6-30
RFC 2889 Test Suite

Partially-Meshed
Figure 6-3.
Partially-Meshed Bidirectional Traffic
Pass/Fail Criteria
Table 6-14. Parameter Pass Criteria Partially-Meshed Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
6-31
RFC 2889 Test Suite

Partially-Meshed
Partially-Meshed Pass Criteria Description Number of sequence errors in the traffic received from the DUT Pass: The number of sequence errors in the traffic received from the DUT was less than or equal to the number you entered. Fail: The number of sequence errors in the traffic received from the DUT exceeded the number you entered.
Sequence Errors
6-32
Chapter 7:
This chapter describes the tests in the Advanced Tcl Script Suite (ATSS) under the following topics: Run Parameters on page 7-1. Setting Up the Tests on page 7-7. DTM Random Interval on page 7-8. Flow Setup on page 7-10. IP Error on page 7-12. Layer 2/Layer 3 on page 7-14. Throughput on page 7-17. Multiple Frame Sizes on page 7-26. Throughput NAT on page 7-29. IP Time to Live on page 7-34. VLAN Broadcast Leakage on page 7-35. VLAN Meshed on page 7-37. VLAN One to Many on page 7-40. Traffic Tester on page 7-42. Mixed IPv4-IPv6 Throughput Test on page 7-46. All Mesh Test on page 7-49. VLAN Forwarding Test on page 7-56.
Run Parameters
This section covers the following topics: Common Run Parameters on page 7-2. Quality of Service (QoS) Settings on page 7-5.
7-1

Run Parameters
Setting the Type of Service Octet or the Traffic Class Octet on page 7-5.
Common Run Parameters
The common run parameters for these tests are described in Table 7-1.
Table 7-1. Field Addresses per Rx Port Binary Search Burst Duration Burst Size Burst Type ATSS Test Run Parameters Usage The number of protocol-level addresses to use on each receive port. Determines whether the tests binary search searches all ports (Linear) or each port individually (Per Port). The number of seconds (s) over which the test bursts traffic. The number of frames to transmit for Traffic Mix set to burst. If Random is selected, then the burst gap is random. If Fixed is selected, then the burst gap is as set in the Min Burst Seconds parameter. Causes jitter to be calculated as well. Causes latency to be calculated as well. If you enable this option, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: The Calibrate Latency option is available only if the IxOS version used is at least 5.10. Check for Leakage If you check this box, the test checks the received frames to ensure that frames were received on the correct interfaces. Specify the type of frame to check for in the Leakage Frame Type field. Only custom is available. The distribution type specifies the pattern in which the frames with different frame sizes can be sent. Currently, a custom pattern must be entered in the Frame Size box. The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. Enables the Ixia hardware to respond to flow control signals. This option is available only for Throughput test. Frame Size The Internet Mix (IMIX) Throughput No Drop test provides you with the opportunity to select a wider range of frame sizes, according to protocol. The percentage of the Initial Rate used as increments during linear searches.
Calculate jitter Calculate latency Calibrate Latency
Distribution Type
Duration
Enable Flow Control
Increment (%)
7-2

Run Parameters
Table 7-1. Field Initial Rate
ATSS Test Run Parameters Usage First transmit rate used in the test. Specify this parameter as a percentage of the selected ports maximum theoretical frame rate. Selects the method used to calculate latency: Cut Through: Delay between the time the first bit of the test frame leaves the Ixia TX port and the time it arrives on the Ixia RX port. Cut Through is normally used with switches and other devices that operate using packet header information. 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: Delay between the time the last bit of the test frame leaves the Ixia TX port and the time its first bit arrives on the Ixia RX port. Store and forward latency is calculated by first determining the Cut Through delay and then substracting the frame length time. Store and Forward is normally used with routers and other devices that operate on the contents of the entire packet. The last transmitted data bit is usually the end of the FCS or CRC, and the first data bit received is as described above for Cut Through. If you want the test to calculate latency, you must set the Calculate Latency option to Yes.
Latency Type
Leakage Frame Type
If you enable the Check for Leakage box, select the type of leaked frame for which to check: Flood: The test checks from frames leaked by the DUT due to flooding. Broadcast: The test checks for broadcast frames leaked by the DUT. Multicast: The test checks for multicast frames leaked by the DUT.
Loss Tolerance (%)
The percentage of total packets allowed to be lost before declaring packet loss. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Max Burst Seconds Max Rate (%)
When random bursts are generated, the maximum time, in seconds (s), used to send burst traffic. The initial rate at which frames are transmitted. This is the percentage of the maximum theoretical frame rate used to calculate the initial frame rate, as specified in RFC 1242. When random bursts are generated, or as the rate for fixed bursts, the minimum time, in seconds (s), used to send bursty traffic. Number of frames to send per trial
Min Burst Seconds No. of Frames
7-3

Run Parameters
Table 7-1. Field
ATSS Test Run Parameters Usage Number of iterations from the Max Rate The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. Specifies which octet the test increments to create additional addresses. This option enables you to increment the host address, allowing you to simulate traffic from multiple hosts using a single pair of ports. For example, if you select two Ixia ports for the test and configure (on the Protocol tab) the First Port Source Address to 198.18.3.100 and Octet to Auto Increment to 3, the Ixia ports used for the test have IP addresses of 198.18.3.100 and 198.18.4.100. If you set Octet to Increment to 4, the first Ixia port generates traffic from 198.18.3.100, 198.18.3.101, 198.18.3.102, and so on, and the second generates traffic from 198.18.4.100, 198.18.4.101, 198.18.4.102, and so on.
No. of Iterations No. of Trials
Octet to Increment
Percent Errors(%) If errorred frames are to be sent during the test, set this value from 1-100, as a percentage of total frames sent. Staggered Transmit If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time. TOS IP Precedence Pattern Traffic Mix Mode The elements in this list are cyclically distributed among the transmit ports. Can be one of the following: Burstnumber of bursts for each frame size (for example, 4 frames per framesize) Percent Line Ratethe line rate percentage for each frame size. Each frame size transmits the number of frames based on the line rate percentage specified for that frame size, as configured in the Frame Size field. Wait Residual The time to wait, in seconds (s), after transmission, to allow the receive frames to settle down.
The common VLAN parameters for the ATSS tests are described in Table 7-2.
7-4

Run Parameters
ATSS VLAN Parameters Description Selects the VLAN type based on the Cisco ISL standard. Either this or Enable 802.1q Tag should be checked. For more information about VLANs, see VLAN
Enable ISL Tag
Quality of Service (QoS) Settings
If the frame size is Standard, Automatic, or Manual, the Enable QoS Settings check box is available for the IPv4 and IPv6 protocols. If it is disabled, there is no special processing of the ToS field on the Tx ports; the reports do not contain ToS information. If it is enabled, a self-explanatory ToS list opens (Figure 7-1).
Figure 7-1.
Enable QoS Settings - ToS List
Setting the Type of Service Octet or the Traffic Class Octet
Depending on whether the IPv4 or IPv6 protocol is selected for your test configuration, the type of service octet (ToS) or the traffic class octet in the header of the Imix packets can be set: to different IP precedences or to standard or custom DSCP (Differentiated Service Code Point) values. The DSCP is a selector for the routers per-hop behaviors.
For the ToS Octet Type field, if you set: the IP Precedence option, you can choose for the Precedence parameter a value in the 0-7 range as representing the level of precedence. the DSCP option, you can choose for the Mode parameter one of the modes available in the drop-down list. The DSCP modes are listed in Table 7-3.
7-5

Run Parameters
Table 7-3.
ATSS Throughput Test - DSCP Defined Modes Description The DSCP value is fixed and the Binary Value and Decimal Value parameters cannot be changed. The default DSCP value is compatible with the default IP precedence value (all zeros).
DSCP Mode Default Mode
Class Selector
It can be set to one of the classes available in the dropdown list. These defined classes are backwards compatible with the IP precedence values (see Table 7-4 on page 7-6). You can choose among three drop precedences (low, medium, high) for each of the 1-4 classes, totaling 12 assured forwarding (AF) possibilities. The DSCP value is fixed (101110 or 46 in decimal). You can modify either of the Binary Value or the Decimal Value fields. This is the only mode where the value field is editable. The valid values for Binary Value are in the 00000011111 range; the valid values for Decimal Value are in the 0-63 range. Note: If a predefined value is manually entered in Custom mode (for example, 101110 (46 decimal value) - Expedited Forwarding) then it is recognized and appears in the list with the predefined value (for example, DSCP EF, not DSCP 46)
Assured Forwarding
Expedited Forwarding Custom
Table 7-4 lists the Class Selector backward compatibilities with the IP precedence values.
Table 7-4. DSCP Defined Modes - Class Selector Backward Compatibilities DSCP - Binary Value 000 000 00 001 000 00 010 000 00 011 000 00 100 000 00 101 000 00 110 000 00 111 000 00 IP Precedence equivalent 0 1 2 3 4 5 6 7 Purpose Best effort Class 1 Class 2 Class 3 Class 4 Express forwarding Control Control
DSCP - Decimal Value 0 8 16 24 32 40 48 56
7-6


Most of the ATSS test parameters are common to all the tests and work the same way on all the tests. The description of each test includes a description of the parameters that are unique for that test. The common run parameters for the ATSS tests are described in Table 7-1 on page 7-2. The other parameters are described as follows: Protocols: All the multicast tests use IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Additionally, when choosing the IP or IPv6 protocols, you can select: The encapsulation protocol over IP: UDP, TCP, or None. The TCP/UDP port used to send traffic: Source Port The TCP/UDP port used as destination: Destination Port If you check the Increment Port option, the TCP/UDP port number is incremented for each Tx-Rx port pair used in the test configuration. This means that the TCP/UDP port number (?TBD) increments per stream. Frame Sizes: All multicast tests allow you to select and test multiple frame sizes. For information about frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: Most of the tests use one-to-many traffic maps, as described in Setting Up the Traffic Map on page 3-11. VLANs: For the parameters common for most of the tests in IxAutomate, see Setting the VLAN Parameters on page 3-42 and How IxAutomate Assigns VLAN IDs on page 3-43. For the common parameters for ATSS tests, see Table 7-2.
7-7

DTM Random Interval
DTM Random Interval

This section covers the following topics: Overview on page 7-8. Run Parameters on page 7-8. Pass/Fail Criteria on page 7-9. Supported Protocols on page 7-9. Results on page 7-10.
Overview
The test determines the DUTs ability to forward bursty traffic. This test uses a many-to-one port mapping to simulate Dual Tone Multimode type traffic. The test randomly transmits bursts of packets at a specified Mb/s rate. The random burst gap is configured in seconds (s) with a minimum gap time and maximum gap time between bursts. Since the burst gap is a random time interval, on a many-to-one configuration, the port transmissions initially start at the same time, but each new burst is likely to start at different times for different ports.
ATSS DTM Random Interval

Ixia Ports DUT
Random Burst Gaps

Maximum gap time
Gap Minimum gap time
Iterations
Figure 7-2.
ATSS DTM Random Interval
Run Parameters
In addition to the common ATSS Run parameters listed in Table 7-1 on page 7-2, this test includes the parameters described in Table 7-5.
7-8

DTM Random Interval
Table 7-5. Parameter Burst Type
DTM Random Interval Run Parameters Description You can choose between Random type and Fixed type. A burst contains a specified number of frames and gaps between frames. The period for waiting the residual frames. The minimum duration for a burst when you choose the Random type. The maximum duration for a burst when you choose the Random type. The duration for a burst (Fixed type only).
Wait Residual Min Burst Seconds Max Burst Seconds Burst Duration
For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1. For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1.
Pass/Fail Criteria
The pass/fail criteria for this test are listed in Table 7-6.
Table 7-6. Parameter Pass Criteria DTM Random Interval Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Supported Protocols
7-9

Flow Setup
Supported Protocols
MAC, IP, IPX
Packet Streams mode
Results
In addition to the standard IxAutomate test results, the following are available in pairs (Tx and Rx): Throughput Loss (%)
Flow Setup
This section covers the following topics: Overview on page 7-10. Run Parameters on page 7-11. Supported Protocols on page 7-12. Results on page 7-12.
Overview
This test determines the number of frames it takes to set up the fast path (sometimes referred to as forwarding database or shortcut) in the DUT. It also calculates the latency, which determines how long it takes to set up the fast path in the DUT. A set number of frames are transmitted into the DUT. At the Ixia receive port, the total number of dropped frames is calculated to determine the minimum number of frames required to set up the forwarding database in the DUT. Latency is also calculated per transmitted packet.
7-10

Flow Setup
A T S S F lo w S e t u p
Ix ia P o r t s DUT
DUT
P o rt -----1 2 3 3 3 4 . . M A C A d d re s s -------------------------0 0 -2 0 -F C -0 A -0 1 -6 A 0 0 -2 0 -A F -B 9 -5 1 -8 B 0 0 -2 0 -F C -0 A -0 1 -1 C 0 0 -2 0 -F C -0 A -0 1 -4 D 0 0 -2 0 -F C -0 A -0 1 -5 2 0 0 -2 0 -A F -3 F -2 6 -E 3
F o r w a r d in g D a ta b a s e
Figure 7-3.
ATSS Flow Setup
Run Parameters
The Run parameters for this test are common to other ATSS tests. See Table 7-1 on page 7-2. For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
7-11

IP Error
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP Packet Streams mode Receive port Capture mode
Results
In addition to the standard IxAutomate test results, this test also reports latency results. The latency results indicate which frame provided the maximum latency value.
IP Error
This section covers the following topics: Overview on page 7-12. Run Parameters on page 7-13. Supported Protocols on page 7-13. Pass/Fail Criteria on page 7-14. Results on page 7-14.
Overview
This throughput test allows the insertion of errorred frames for IP traffic in a valid traffic transmission. Errors include bad IP checksum, valid IP checksum with invalid CRC, and bad IP checksum with invalid CRC. The percentage of error frames can be configured. The percentage of error frames (the sum of the percentages set for the Error Distribution parameters available in the Test Setup window) is calculated directly from the capacity of the port. If the sum of percentages is bigger than the value set for the Initial Rate parameter, the sum is decreased. For example: Initial Rate is set to 10%, the Error Distribution parameters are set to IP Errors 5%, IP and FSC Errors 5%, FCS Errors 5%, the sum of percentages is 15% of the capacity of the port.
Because the Initial Rate is only 10%, the Error Distribution parameters values are decreased to: IP Errors 3.33%, IP and FSC Errors 3.33%, FCS Errors 3.33%.
7-12

IP Error
ATSS IP Error
Ixia Ports
DUT
Normal packets Packets containing errors
Figure 7-4.
ATSS IP Error
Run Parameters
You can set the Percent Errors (%) parameter. It represents the percentage of errors inserted into a valid traffic transmission. For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Supported Protocols
The protocol supported by this test is:

Supported Protocols Features Required on Ports Transmit port IP Packet Streams mode Receive port Capture mode
7-13

Layer 2/Layer 3
Pass/Fail Criteria
The pass/fail criteria for this test are listed in Table 7-7:
Table 7-7. Parameter Pass Criteria IP Error Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of received frames that contained errors. Pass: The percentage of frames that contained errors was equal to or less than the percentage you entered. Fail: The percentage of frames that contained errors was greater than the percentage you entered. Total RX Errors Total number of received frames that contained errors. Pass: The number of frames that contained errors was equal to or less than the number you entered. Fail: The number of frames that contained errors was greater than the number you entered.
% RX Errors
Results
In addition to the standard IxAutomate test results, the following results are available for this test: Throughput (f/s) Frame Loss, in frames and % Rx Errors
Layer 2/Layer 3
Overview
This test determines the maximum rate at which the DUT can transmit a mixture of layer 2 and layer 3 frames. This throughput test transmits a mixture of Layer 2 (MAC) and Layer 3 (IP) frames of a particular frame size and calculates the throughput of the DUT. The test checks the performance of the switch when it receives Layer 2 (MAC) frames along with higher application level data (IP), a situation which relates more closely with real-world scenarios. Optionally, latency may also be calculated.
7-14

Layer 2/Layer 3
ATSS Throughput Layer 2-Layer 3

Ixia Ports DUT
Positive Increment (%) value
Frame rate
Iterations
Negative Increment (%) value

Frame rate
Iterations Layer 2 traffic / throughput Layer 3 traffic / throughput
Figure 7-5.
ATSS Layer 2-Layer 3
Run Parameters
Pass/Fail Criteria
Table 7-8 lists the pass/fail criteria for this test.

Table 7-8. Parameter Pass Criteria Layer 2 / Layer 3 Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
7-15

Layer 2/Layer 3
Table 7-8. Parameter Load Rate
Layer 2 / Layer 3 Pass Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Amount of time required by the DUT to forward frames. To specify the unit of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Latency Std. Deviation Amount of variation from the mean average in the DUTs latency. To specify the unit of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of these two methods to calculate the standard deviation: Average/Port: The test averages the standard deviation over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest standard deviation experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The standard deviation was less than or equal to the value you specified. Fail: The standard deviation exceeded the value you specified.
7-16

Throughput
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6 Packet Streams mode QoS Receive port
Results
In addition to the standard IxAutomate test results, this test also reports: Throughput Average Latency Latency Standard Deviation
Throughput
This section covers the following topics: Overview on page 7-17. Run Parameters on page 7-20. The Non-IMIX Scenario Settings on page 7-21. Pass/Fail Criteria on page 7-21. Supported Protocols on page 7-23. Results on page 7-23.
Overview
This test determines the maximum rate at which the DUT can transmit frames. This test is similar to the RFC 2544 Throughput test. It allows you to calculate the maximum DUT Throughput, with Latency and/or Jitter, using either a binary or a linear search. If binary search is selected, the test iterates until it finds the no drop rate, then using that number runs a final time and calculates the latency. The test can transmit either homogenous or IMIX traffic. IMIX is a mixture of frames intended to mimic different frame sizes and TCP/UDP port combinations commonly seen on the Internet. A one-to-one, one-to-many, or many-to-one port mapping is used with a minimum of two ports required. Per-port or per-VLAN flow statistics can be configured. Also, DHCP is supported for automatic client IP addressing.
7-17

Throughput
ATSS Throughput
Ixia Ports DUT
Binary Search Frame Rate Packet loss
No packet loss Iterations
Figure 7-6.
ATSS Throughput
The test uses frame sizes which can be: Standard Automatic Manual IMIX - a mixture of frames intended to mimic frame sizes commonly seen on the Internet.
You can set how the IP or IPv6 addresses to be assigned to all the ports used for a certain test: Manually setting the IP address and the mask for each port Manually using a simple automatic arithmetic generation based on the provided parameters, namely First Port Source Address and Mask Width Automatically using a DHCP server by enabling the Get IP/IPv6 Addresses using DHCP option. The IP addresses assigned by the DHCP server are used during the whole test, for all trials and for all frame sizes. This option can be used for single or multiple interfaces per port, with or without VLAN tags, either with automatic traffic map or with manual traffic map.
For both IP and IPv6 protocols, when choosing to assign ports automatically, the Assign Addresses to Excluded Ports option is available. It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports. When using manual traffic map, the VLANs parameters may be used to enable the outer VLAN tag and the inner VLAN tag (Stacked VLAN (Q in Q)): For the outer VLAN, you may set the VLAN ID, the No. of addresses and the Octet to Increment (these are available in the Port Names window, which opens if the Per Port Settings button is clicked);
7-18

Throughput
For the stacked VLAN, you can define the Inner VLAN ID (these are available in the Port Names window, which opens if the Per Port Settings button is clicked).
If the Stacked VLAN (Q in Q) option is checked, the Send Mac Only option from the Learning Frames section is automatically activated. For example, the double VLAN tagging can be useful for Internet Service Providers, allowing them to use VLANs internally while handling traffic from clients that is already VLAN tagged. The maximum throughput is determined using a binary or a linear search. For binary searches, the initial rate should be set to the theoretical maximum. It can be set in terms of: Payload (Kb/s) Max Rate (%) Frames/Second (f/s) For linear searches, the initial rate should be set under the expected maximum and the step size should reflect the desired resolution. It can be set in the same terms as in the binary search.
While performing the search, the test may also optionally calculate latency and jitter. For IMIX frame size mode, no jitter calculation is available. The defined latency types are: Cut Through Store and Forward For calculating jitter and latency at the same time, Cut Through latency type must be chosen. More accurate latency may be obtained by using each ports packet groups (as opposed to capture buffer). When doing so, however, no Jitter measurements are available. A fixed or user-defined pattern can be included in the transmitted frames by enabling the Pattern Verify option (the Data Pattern and User Pattern parameter fields are available). The test verifies whether the frames were corrupted or not when forwarded by the DUT. The verification is performed by capturing a fixed number of frames and matching the pattern of every byte with that of the bytes transmitted for those frames. For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. Also see Quality of Service (QoS) Settings on page 7-5 for additional information about the frame size settings. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
7-19

Throughput
For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1.
Run Parameters
The common run parameters are described in Table 7-1 on page 7-2. If the frame size mode is: Standard, Automatic, or Manual
Then you have the following possibilities: If you enable the Calculate Jitter check box, the Calculate Latency check box is automatically enabled, Latency Type is preset to Cut Through and the Calibrate Latency parameter becomes available. If you enable Calculate Latency, but not Calculate Jitter, you can set Latency Type to Store and Forward.
If you choose the IMIX frame size mode, then: No jitter calculation is available. The Latency Type can be set to Cut Through or Store and Forward.
For more information about setting the frames using the Imix frame size mode, see Chapter 3, Imix Mode. An additional option is added, as compared to the other tests that are using the IMIX mode, allowing you to set the number of transmitted frames by bandwidth percentage or by weight. You can choose from the BW(%)/Weight Column Caption available drop-down list one of these two options: Bandwidth Percent or, Weight
The name for the BW(%)/Weight column changes in concordance with your choice.
Notes: 1. The Throughput test transmits only stateless traffic; no stateful traffic in sent using this test. 2. The protocols available in the Protocol drop-down list, of the Add Packets Parameters window, are defining the number of source and destination ports. 3. In the Frame Data section, if you set the Protocol to MAC protocol, the Random MAC Addresses parameter becomes available. When this option is enabled, the MAC addresses are uniformly distributed over the network processors of a switch device.
You can configure multiple IP addresses per port using the Enable 802.1 q Tag and Multiple IPs Per Port option, which allows you to create multiple interfaces on a port with or without VLANs. You can also get statistics for each
7-20

Throughput
source IP address if you enable Calculate Latency and choose the Packet Group mode for Capture Type.
The Non-IMIX Scenario Settings
When using fixed frame-sizes (Standard, Manual, or Automatic), for each source IP (per Tx port), you can set ToS parameters. All packets having the same source IP have the same ToS setting. This implies that each Tx port must be configured with multiple source IPs in order to generate packets with different ToS settings. The settings that are necessary to achieve this are: In the Test Setup tab: Calculate Latency checked Calculate Jitter unchecked In the Traffic Setup tab: Traffic Map mode set Manual mode Frame Data section: set Protocol as IP or IPv6 Enable 802.1q and Multiple IPs per port checked, Use the Per Port Settings button and set, in the Per Port Settings window, the No. of Addresses parameter to any value greater than 1 and Octet to increment to any value greater than 0 for each Tx port.
Note: If at least one of the options is not set as indicated above, only one source IP address is set per port and all packets have the same ToS setting.
Pass/Fail Criteria
Table 7-9 on page 7-21 lists the pass/fail criteria for this test. The pass/fail criteria are applied to the Rx rate.
:
Throughput Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
Pass Criteria
7-21

Throughput
Throughput Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
% Load Rate
Latency
7-22

Throughput
Supported Protocols

Frame Size Supported Protocols Features Required on Ports Transmit port Standard, Automatic, Manual IMIX MAC, IP, IPX, IPv6, VLANs IP, IPv6, VLANs Packet Streams mode Receive port Capture mode
Results
This section covers the following topics: General Results on page 7-23. Non-Imix Traffic Results on page 7-24. Imix Traffic Results on page 7-25.
General Results
For binary searches, the available results are: Tx Rx OLoad (f/s) %MaxTxRate AvgTxRunRate AvgRxRunRate
For linear searches, the available results are: Tx Rx TxFrames RxFrames Frame Loss TxTput (f/s) %TxTput %Rx it is calculated applying the formula: 1-(Frame loss).
For each trial, the available results are:
7-23

Throughput
Tx Rx TxTput (f/s) %TxTput
For Latency calculations, the following results are available: MinLatency (ns) MaxLatency (ns) AvgLatency (ns)
For Jitter calculations, the available results are: MinLatency (ns) MaxLatency (ns) AvgLatency (ns) StdDev (ns)
If Pattern Verify is set, the following results are available: Data Integrity Frames Data Integrity Errors
Non-Imix Traffic Results

For the Non-Imix traffic, two types of results are available: Result Metrics and Aggregate Metrics. The following Result Metrics are available: Tx Rate (% Line Rate) Tx Tput (fps) MinLatency (ns) MaxLatency (ns) AvgLatency (ns) Tx Frames Rx Tput Rx Frames Frame Loss
The aggregate results represent the sum of the metric on all the receiving/transmitting ports. The following Aggregate Metrics are available: Agg Tx Tput (fps) Max Tput (fps)
7-24

Throughput
Agg Tput (Mbps) Max Tput (Mbps) Agg Tput Rate (%) Agg Rx Rate (fps) Agg Min Latency (ns) Agg Max Latency (ns) Agg Avg Latency (ns) Agg Sum Data Frames Agg Sum Data Errors Agg Frame Loss Agg Frame Loss (%)
Imix Traffic Results

For the Non-Imix traffic, three types of results are available: Result Metrics Aggregate Metrics Aggregate Imix Metrics
The following Result Metrics are available: Tx Rate (% Line rate) Source IP Tx Tput (fps) Min Latency (ns) Max Latency (ns) Avg Latency (ns) TxFrames RxFrames Frame Loss (%) ToS Data Frames Data Errors
The aggregate results represent the sum of the metric on all the ports having the same Source IP type. The following Aggregate Metrics are available: Agg Tx Rate (% Line rate) Source IP Agg Tx Tput (fps)
7-25

Multiple Frame Sizes
Agg Tx Tput (Mbps) Agg Rx Rate (fps) Agg Avg Latency (ns) ToS Agg Sum Data Frames Agg Sum Data Errors Agg Frame Loss Agg Frame Loss (%)
The aggregate imix results represent the sum of the metric on all the receiving/ transmitting ports. The following Aggregate Imix Metrics are available: Agg Tx Rate (% Line rate) Agg Tx Tput (fps) Agg Tx Tput (Mbps) Agg Avg Latency (ns) Agg Sum Data Frames Agg Sum Data Errors

Overview
This test determines the DUT's ability to transmit a mixture of frame sizes. This throughput test transmits a mixture of frames with up to eight frame sizes. Each frame size is transmitted in a serial fashion for a user-defined duration. This test simulates a real-world scenario where data of any size could be transmitted through switches and routers. Frame transmission can be either unidirectional or bidirectional. Optionally, jitter may also be calculated.
7-26

ATSS Multiple Frame Sizes

Ixia Ports DUT
Iteration 1 2 3 4 . . .
Sam ple Frame Size Patterns
Figure 7-7.
ATSS Multi Frame Sizes
Run Parameters
Pass/Fail Criteria

Table 7-10. Parameter Pass Criteria Multiple Frame Sizes Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
7-27

Multiple Frame Sizes Pass Criteria (Continued) Description Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Latency
Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Supported Protocols
7-28

Throughput NAT
Supported Protocols
Features Required on Ports Transmit port Receive port QoS
MAC, IP, IPX, IPv6
Packet Streams mode
Results
In addition to the standard IxAutomate test results, this test also reports: Throughput Average Latency Latency Standard Deviation
Throughput NAT
This section covers the following topics: Overview on page 7-29. Port Selection and NAT Direction on page 7-30. Run Parameters on page 7-31. Pass/Fail Criteria on page 7-32. Supported Protocols on page 7-33. Results on page 7-33.
Overview
This test determines the maximum rate at which a NAT (Network Address Translation) router can perform NAT on incoming TCP or UDP packets and then forward the traffic. The throughput NAT test is designed to test the router's ability to translate addresses from the private address space to the public, from the public address space to the private, or both at the same time. For each iteration, the test displays the DUT's throughput and minimum, maximum, and average latencies. If the test performs the first iteration using the binary search algorithm and no frames are received, then a second iteration is performed; after that, if no frames are received, the test stops; otherwise, the binary search algorithm continues.
Note: For this test, the minimum frame size for the TCP packets is 70 bytes. Private Addresses (from RFC 1918): 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
7-29

Throughput NAT
Port Selection and NAT Direction
This section covers the following topics: General on page 7-30. NAT Direction: Private to Public on page 7-30. NAT Direction: Public to Private on page 7-30. NAT Direction: Both Directions on page 7-31.
General
For this test, instead of transmit and receive ports, consider ports as being either Public or Private. Private ports generate traffic containing private source IP addresses. The DUT forwards the traffic to the Public port. Public ports generate traffic containing public source IP addresses. The DUT forwards the traffic to the Private port.
When you select port pairs for the traffic map for this test, it considers the first port selected to be the Private port, and the second port to be the Public port. For example, if you first select port 1.1.1 (which would normally be the Source port), and then select 1.1.2 (normally, the Destination port), the test adds 1.1.1 --> 1.1.2 to the traffic map. 1.1.1 is the Private port and 1.1.2 is the Public port. The test automatically builds the traffic map for the Private-to-Public (1.1.1 --> 1.1.2) direction. If you run the test in the Public-to-Private direction, the test automatically creates the traffic map for that direction using the same port pair; you do not need to select additional port pairs.
NAT Direction: Private to Public

If you select Private to Public as the NAT Direction, the Private port generates traffic in which the Source IP fields contain private IP addresses from an internal pool maintained by the test. The Private Addresses parameter determines the number of addresses in the pool. The DUT should replace the private IP addresses with public addresses and forward the traffic to the Ixia Public port. The test checks the forwarded traffic to ensure that all the packets are received on the Ixia Public port. If any loss occurs, the test uses a binary search algorithm to find a lower rate and re-transmits the traffic. The test continues searching and re-transmitting until it finds a rate at which the DUT does not lose any frames.
NAT Direction: Public to Private

If you select Public to Private as the NAT Direction, the test begins by transmitting one packet for each private address from the Ixia Private port to the Ixia Public port. The packets' addresses are based on the First Port Source Address parameter, and the total number of sent packets depends on the Number of Private Addresses parameter.
7-30

Throughput NAT
The DUT should replace the private IP addresses with NAT addresses and forward the packets to the Ixia Public port. The test then retrieves the source IP address and TCP/UDP port number from them. It uses this information to build the traffic for the Public to Private direction. Once the test has built the traffic for the Public to Private direction, it begins transmitting large amounts of traffic to test the DUT's throughput under NAT. The test initially transmits at the rate you specify, which is typically the maximum theoretical rate based on the port speed. The DUT should replace the NAT addresses with private addresses, and forward the traffic to the Ixia Private port. The test checks the amount of traffic received from the DUT. If any loss occurred, the test uses a binary search algorithm to find a lower rate and re-transmits the traffic. The test continues searching and retransmitting until it finds a rate at which the DUT does not lose any frames.
NAT Direction: Both Directions

If you select Both Directions as the NAT Direction, the test initially performs the address and port number learning phase for the Public to Private direction, then it transmits traffic in both directions at the same time. The search for a no-loss rate functions as described under Public to Private and Private to Public.
ATSS Throughput NAT test
Public to Private SRC IP: 210.128.88.6 DEST IP: 10.1.1.12 Local network 10.1.1.0 / 24 SRC IP: 10.1.1.12 DEST IP: 210.128.88.6 DUT SRC IP: 210.128.88.6 DEST IP: 136.1.1.26 Public network 210.128.88.0 / 24 SRC IP: 136.1.1.26 DEST IP: 210.128.88.6
Private to Public
Local network 10.1.1.0 / 24
SRC IP: 10.1.1.12 DEST IP: 210.128.88.6 SRC IP: 210.128.88.6 DEST IP: 10.1.1.12 DUT SRC IP: 210.128.88.6 DEST IP: 136.1.1.26 SRC IP: 136.1.1.26 DEST IP: 210.128.88.6
Public network 210.128.88.0 / 24
Figure 7-8.
ATSS Throughput NAT
Run Parameters
The following run parameters are different from standard settings or unique to this test. The available IP transport protocols are:
7-31

Throughput NAT
TCP or UDP
The Private Addresses parameter determines the number of addresses in the pool. If you enable the Set TCP SYN Flag check box, all the TCP packets sent have set the TCP SYN flag and each packet sent is treated by the DUT as a new TCP connection. IMPORTANT: The test results are strongly decreased if the Set TCP SYN Flag check box is enabled. Do not consider the results invalid before checking if this option was enabled for the test you run. You can set the NAT Direction: Private to Public - If you select it as the NAT Direction, the Private port generates traffic in which the Source IP fields contain private IP addresses from an internal pool maintained by the test. Public to Private - If you select it as the NAT Direction, the test begins by transmitting one packet for each private address from the Ixia Private port to the Ixia Public port. Both Directions - If you select it as the NAT Direction, the test initially performs the address and port number learning phase for the Public to Private direction, then it transmits traffic in both directions at the same time.
If you choose the Public to Private NAT direction, the Use UDP/TCP Ports Retrieved from Translations parameter is available. If you enable it, the source TCP/UDP ports from the first frames received are used as destination ports for the traffic sent. If this option is not enabled, the packets are sent to the TCP/UDP destination ports that you have already set in the Advanced Parameters. For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria

Table 7-11. Parameter Pass Criteria Throughput NAT Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
7-32

Throughput NAT
Throughput NAT Pass Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
% Load Rate
Latency
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP Packet Streams mode QoS Receive port
Results
In addition to the standard IxAutomate test results, this test also reports: Throughput
7-33

IP Time to Live
Minimum Latency Maximum Latency Average Latency
IP Time to Live
Overview
This test verifies the correct operation of the Time-To-Live (TTL) field in the IP header when traffic is forwarded to the DUT. The TTL field in the IP header is decremented every time an IP frame passes through a DUT. A few validation streams of IP data are transmitted to the switch with different TTL values. The output is measured to determine packet loss, valid CRC, and correct decrementing of the TTL.
ATSS Time-to-Live
Ixia Ports DUT
Packets with valid TTL Packets with TTL incremented by DUT Packets received with invalid TTL or with invalid TTL after being incremented
Figure 7-9.
ATSS IP Time To Live Test
Run Parameters
The Run parameters for this test are common to other ATSS tests. See Table 7-1 on page 7-2. For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7.
7-34

VLAN Broadcast Leakage
For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria
:Table 7-12 lists the pass/fail criteria for this test.

Table 7-12. Parameter Pass Criteria IP Time to Live Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The DUT correctly decremented the TTL values of all the packets that it forwarded, and it did not forward any packets it received with a TTL value of 1 or 0. Fail: One or more packets forwarded by the DUT were incorrectly decremented or were received by the DUT with a TTL of 0 or 1.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6 Packet Streams mode Receive port Capture mode
Results
In addition to the standard IxAutomate test results, this test also reports: Tx TTL value Rx TTL value

7-35

Overview
This test checks for leakage across VLAN broadcast domains. Whether or not the receive ports receive any frames depends on the test configuration: If the receive ports are on the same VLAN as the transmit port, they should receive broadcast frames. If the receive ports are on a different VLAN from the transmit port, they should not receive any frames. If they receive any frames, that indicates that the DUT is leaking frames across VLAN boundaries.
ATSS VLAN Broadcast Leakage test

VLAN 11
DUT Ixia chassis VLAN 11
Transmit and recieve ports on same VLAN Transmit and recieve ports on different VLANs
VLAN 12, 13, 14
DUT
Figure 7-10. ATSS VLAN Broadcast Leakage
Run Parameters
Pass/Fail Criteria
7-36

VLAN Meshed
VLAN Broadcast Leakage Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The DUT forwarded all VLAN-tagged frames to the correct ports. Fail: The DUT forwarded one or more VLAN-tagged packets to the wrong port.
Enable Pass Criteria
Supported Protocols
The protocol supported by this test is:

Results
In addition to the standard IxAutomate test results, this test also reports: Rx VLAN Tagged Frames Leakage
VLAN Meshed
Overview
In this throughput test, 802.1q VLAN tagged frames are sent with unique VLAN IDs. All ports transmit and receive traffic at a specified transmit rate such that each of the interfaces on the DUT transmits frames and receives frames addressed to and from all the other interfaces under test. MAC, IP, or IPX frames may be used as part of the stream validation. Frames are tagged with the appropriate VLAN ID, transmitted to the DUT, and checked on the receive port to determine receipt of the intended packets with the correct VLAN IDs. Latency and latency standard deviation may optionally be calculated during the test.
7-37

VLAN Meshed
ATSS VLAN Mesh test
Ixia chassis DUT Example of VLAN ID Assignment First VLAN ID: From port: To port: Port 1,1,1 1,1,2 1,1,3 1,1,4 11 1,1,1 1,1,4 Traffic Map Port (VLAN ID) Tx 1,1,1 (11) 1,1,2 (12) 1,1,3 (13) 1,1,4 (14) Rx 1,1,2 (12) 1,1,1 (11) 1,1,1 (11) 1,1,1 (11) / / / / 1,1,3 1,1,3 1,1,2 1,1,2 (13) (13) (12) (12) / / / / 1,1,4 1,1,4 1,1,4 1,1,3 (14) (14) (14) (13)
Assigned VLAN ID 11 12 13 14
Figure 7-11. ATSS VLAN Meshed
Run Parameters
Pass/Fail Criteria

Table 7-14. Parameter Pass Criteria VLAN Meshed Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
7-38

VLAN Meshed
VLAN Meshed Pass Criteria (Continued) Description Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Latency
Supported Protocols
7-39

VLAN One to Many
Supported Protocols
MAC, IP, IPX, VLANs
Packet Streams mode
Results
In addition to the standard IxAutomate test results, this test also reports: Rx VLAN Tagged Frames Throughput Avg Latency (ns) Latency Std Deviation (ns)
VLAN One to Many

Overview
This test determines the DUT/SUT's ability to forward VLAN tagged frames over the correct paths. In this throughput test, 802.1q VLAN tagged frames are sent with unique VLAN IDs to two VLANs. Either MAC, IP, or IPX frames may used as part of stream validation. Frames are tagged with the appropriate VLAN ID, transmitted to the DUT, and checked on the receive port to determine receipt of the intended packets with the correct VLAN IDs. Latency and latency standard deviation may optionally be calculated during the test.
NOTE: If the Checking for Vlan Leakage option is enabled, the Learning Frames frequency should be set to On Trial or On binary iteration. This is needed because the checking is done for every trial.
7-40

VLAN One to Many
ATSS VLAN One-to-Many test
Ixia chassis 3 bits 2 bytes PRE SF DA SA TCI
1 bit 12 bits DUT
P C VLAN
T/L
Payload
FCS
Standard Ethernet frame fields 4 bytes PRE Preamble; synchronizes traffic between nodes SF DA SA T/L FCS Start Frame delimiter; marks start of header Destination MAC Address Source MAC Address Ethernet II Type or 802.3 Length Frame Check Sequence; CRC for frame contents VLAN TCI P C
VLAN 802.1p and Q fields
Tag Control Info. '8100' indicates frame uses 802.1p and Q tags 802.1p Priority level (0-7) Canonical indicator; indicates that MAC addresses are in canonical format. Ethernet uses '0' value VLAN ID (0-4095). Identifies which VLAN frame belongs to.
Figure 7-12. ATSS VLAN One to Many
Run Parameters
Pass/Fail Criteria

Table 7-15. Parameter Pass Criteria VLAN One to Many Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
7-41

Traffic Tester
VLAN One to Many Pass Criteria (Continued) Description Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Supported Protocols

Supported Protocols Features Required on Ports Transmit port MAC, IP, IPX, VLANs Packet Streams mode Receive port Capture mode
Results
In addition to the standard IxAutomate test results, this test also reports: Rx VLAN Tagged Frames Throughput Frame Loss (%)
Traffic Tester
This section covers the following topics: Overview on page 7-42. Run Parameters on page 7-44. Pass/Fail Criteria on page 7-44. Results on page 7-45.
Overview
Traffic Tester performs data plane testing based on custom streams defined in IxExplorer. The streams can be defined manually using the Packet Stream Editor in IxExplorer, or created using the Traffic Generation Map in IxRouter or IxNet-
7-42

Traffic Tester
work. Once the streams are configured, ScriptGen is used to build a TCL script. This script is then launched by Traffic Tester for data plane testing.
ATSS Traffic Tester
Binary Search (Loss Tolerance = 0%) Stream Traffic configuration from IxExplorer Frame Rate Packet loss
No packet loss DUT Ixia chassis Iterations
Figure 7-13. ATSS Traffic Tester
When using the Traffic Tester, the workflow is: Use IxExplorer to define streams for each Ixia test port participating in the measurement. Alternatively, the Traffic Generation Map in IxRouter can be used to generate the streams for the Ixia test ports. Run IxAutomate specifying parameters as: traffic destination, frame rate, frame sizes, measurement tag offset, and so on
A test can be performed using the existing chassis configuration or by executing a Tcl program that creates the chassis state. This Tcl program can be easily created using IxExplorer/IxRouter and Scriptgen. You can run a test with either the standard frame size choices, or by using the frame sizes established in the defined streams. In the latter case, only one frame size iteration is run. Traffic can be mapped on a port-to-port basis, or individual streams can be sent to individual ports. Maximum throughput is determined by using a binary search routine with two techniques: Per Port: all streams on a port are binary searched together, with all streams locked with the same ratio to each other. Both Packet Stream and Advanced Stream Scheduler modes are supported. Per Stream: each stream is binary searched individually. Only the Advanced Stream Scheduler mode is supported.
If the test performs the first iteration using the binary search algorithm and no frames are received, then a second iteration is performed; after that, if no frames are received, the test stops; otherwise, the binary search algorithm continues.
7-43

Traffic Tester
For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1. For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1.
Run Parameters
The following Run parameters are different from standard settings or unique to this test. Traffic tester needs to place packet group IDs within packets, with their offsets indicated by: Tx instrument tag offset parameter
and Rx instrument tag offset parameter
Ensure that these offsets do not interfere with your frame data. If VLAN is not used, the values for these two parameters should be equal. The Chassis Configuration File allows you to specify the configuration used for a test: If you specify a chassis configuration file (a TCL file specified in the appropriate field), this is loaded prior to running the test, and the test runs with the configuration defined in the file. If you do not specify a chassis configuration file (Chassis Configuration File is empty), no file is loaded and the test runs with the configuration that exists on the port.
Pass/Fail Criteria
The pass/fail criteria for this test are listed in Table 7-16.
Table 7-16. Parameter Pass Criteria Throughput Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
7-44

Traffic Tester
Throughput Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
% Load Rate
Latency
Results
In addition to the standard IxAutomate test results, the following results are available in pairs (Tx and Rx): Throughput Frame count Frame loss Frame rate Bandwidth in % and Mb/s Data integrity errors
7-45

Mixed IPv4-IPv6 Throughput Test

Overview
This test determines the maximum rate at which the DUT receives and forwards frames without any frame loss when transmitting a combination of IPv4 and IPv6 traffic. Frames are initially sent at a user-specified rate, generally the maximum theoretical rate based on the speed of the port. A binary or linear search routine is used to find the maximum No Drop Rate of the device or test network. A userdefinable mixture of IPv4 and IPv6 packets is transmitted at a starting line rate, and the test iterates until the maximum throughput is determined. Both source and destination IP addresses can be incremented to define multiple flows per port. A one-to-one port mapping, using a minimum of two ports, is required for this test. The test results show the total transmitted and received frames per port, frame loss per port, and the maximum throughput.
ATSS Mixed IPv4-IPv6 Throughput

Ixia Ports DUT
Binary Search (Loss Tolerance = 0%) Frame Rate Packet loss
No packet loss Iterations
IPv4 Frames IPv6 Frames
Figure 7-14. ATSS Mixed IPv4-IPv6 Throughput Test
You can set how the IPv4 or IPv6 addresses are assigned to all the ports used for a certain test: Manually setting for each port the IPv4/IPv6 address. To set parameters for each port separately, click the Per Port IPv4 button or the Per Port IPv6
7-46

button. If the Multiple Addresses Per Port option is enabled, then multiple fields related to it are available. Automatically setting the First Port Source Address and the First Port Gateway/DUT for each protocol type. Also, the VLAN parameters are available for easily setting up the streams to have 802.1q tag.
You can use either the automatic traffic map or the manual traffic map, with single or multiple interfaces per port, with or without VLAN tags. The maximum throughput is determined using a binary or linear search. For binary searches, the initial rate should be set to the theoretical maximum. It can be set in terms of: Payload, in Kb/s Max Rate (%) Frames/Second (f/s) For linear searches, the initial rate should be set below the expected maximum and the step size should reflect the desired resolution. It can be set in the same terms as for the binary search.
Run Parameters
Table 7-17 lists the run parameters that are different from the standard settings or unique for this test.
Table 7-17. Parameter IPv6 Traffic (%) Enable Multiple Addresses per Port Multiple Addresses Only on Rx Mixed IPv4-IPv6 Throughput Test - Run Parameters Description The percentage of IPv6 traffic from the total generated traffic If you click this parameter, you can set more than one address per port. It influences traffic over interfaces creation and stream building. If you click this parameter, more than one address can be configured on the Rx ports. This option introduces the restriction for the streams to have only one source address (MAC or IP) set per port. You cannot set this parameter. It has an informal purpose and it reflects the iteration step as set in Load Rate.
Iteration Step (set below)
For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1. For information on other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1.
7-47

Pass/Fail Criteria
Table 7-18 lists the pass criteria available for the Mixed IPv4-IPv6 Throughput Test.
Table 7-18. Parameter Pass Criteria Mixed IPv4-IPv6 Throughput Test Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs Packet Streams mode Receive port Capture mode
Results
Table 7-19 describes the test results available for the Mixed IPv4-IPv6 Throughput test.
Table 7-19. Parameter %TxTput TxTput (f/s) Mixed Ipv4-IPv6 Throughput Test Results Description Transmit throughput, as a percentage of the theoretical maximum port speed Transmit throughput, in frames per second (f/s)
7-48

All Mesh Test
All Mesh Test

This test determines the maximum rate at which the DUT receives and forwards frames without any frame loss. Frames are initially sent at a user-specified rate, generally the maximum theoretical rate based on the speed of the port. A binary, linear, or fixed search type can be selected to determine the maximum no drop rate. This test supports multiple interface groups and multiple traffic maps. The available options for configuring the traffic map are: many-to-many or one-toone mapping. The results of the test show the throughput rates in frames per second (f/s) obtained for each frame size. This section covers the following topics: General Information About the Test on page 7-49. Run Parameters on page 7-52. Test Setup Parameters on page 7-54. Pass/Fail Criteria on page 7-55. Supported Protocols on page 7-56. Results on page 7-56.
General Information About the Test
The All Mesh test transmits traffic at the highest rate configured on its first attempt between groups of ports. The rate is configured as a percentage of the maximum port speed. This test can combine multiple traffic maps in a single test, such as full mesh and partial (backbone) mesh. For the full mesh traffic map, you must create two identical interfaces groups, but with different names. To set up an All Mesh test: 1. Create Interface Groups in the specific tab. Fill in the Interface Group Name field. If you check the VLAN box, a new tab displays. For details about VLAN parameters, see Table 7-20.
Table 7-20. Parameters VLAN Id Id Step Id Step/X Addr VLAN Priority All Mesh VLAN Parameters Description The ID of the VLAN. The VLAN ID increment to spread over a range of interfaces/ports in the Interface Group. The number of interfaces that use the same VLAN ID. The first priority number in the 0 - 7 range that spreads over the range of interfaces/ports in the Interface Group.
7-49

All Mesh Test
Table 7-20. Parameters Priority Step
All Mesh VLAN Parameters (Continued) Description The priority increment. The number of interfaces that send traffic using the same priority in the VLAN tag.
Pri Step/X Addr
2. In the Port tab, check the ports that are included in the Interface Group. 3. Select the number of interfaces that are spread over the number of ports from an Interface Group. For example, 4 ports and 8 interfaces, means that each port simulates 2 interfaces. 4. Select the Interface Type from the available choices: MAC, DHCPv4, IPv4, DHCPv6, IPv6. The MAC, IPv4, IPv6 tabs optionally display if the corresponding setting is chosen from the Interface Type. For details about the available parameters, see Table 7-21, Table 7-22, and Table 7-23 on page 7-51.
Table 7-21. Parameter MAC Start All Mesh MAC Tab Description The first MAC address in the range of MAC addresses that spreads over the range of interfaces/ports in the Interface Group. The MAC increment to spread over a range of interfaces/ports in the Interface Group. The MAC address used for random MAC assignment. The X represents a random generated hexadecimal digit. When enabled, the MAC Mask is used to determine MAC addresses over a range of interfaces/ports.
MAC Step MAC Mask
Random MAC
All Mesh IPv4 Tab Description The first IPv4 address in the range of IPv4 Addresses that spreads over a range of interfaces/ports in the Interface Group. The increment of the IPv4 addresses corresponding to the simulated interfaces of a port. The increment of the IPv4 addresses between ports. The IPv4 network mask. The first IPv4 Gateway in a range of IPv4 Gateways that spreads over a range of interfaces/ports in the Interface Group.
Address Start
Addr Step Addr Step/Port Mask Gw Start
7-50

All Mesh Test
Table 7-22. Parameter Gx Step Step/X Addr
All Mesh IPv4 Tab (Continued) Description The IPv4 Gateway increment to spread over a range of interfaces. The number of interfaces that use the same gateway. For example: Ports=4; Interfaces=12; Address Start: 180.10.1.35; Address Step: 0.0.0.1 Address Step/port: 0.0.1.0 Each port has assigned 3 interfaces and the IPv4 addresses are incremented by 0.0.1.0 at each three interfaces: Port 1: 180.10.1035; 180.10.1.36; 180.10.1.37 Port 2: 180.10.1035; 180.10.1.36; 180.10.1.37 Port 3: 180.10.1035; 180.10.1.36; 180.10.1.37 Port 4: 180.10.1035; 180.10.1.36; 180.10.1.37 Gateway Start: 180.10.1.1 Gateway Step: 0.0.1.0 Step/X Address: 3 The IPv4 Gateway addresses are incremented by 0.0.1.0 at each 3 interfaces: Port 1: Gw address: 180.10.1.1 Port 2: Gw address: 180.10.2.1 Port 3: Gw address: 180.10.3.1 Port 4: Gw address: 180.10.4.1
All Mesh Test IPv6 Tab Description The first IPv6 address in the range of IPv6 Addresses that spreads over a range of interfaces/ports in the Interface Group. The increment of the IPv6 addresses corresponding to the simulated interfaces of a port. The IPv6 start increment class on each port. The IPv6 network mask The first IPv6 Gateway in a range of IPv6 Gateways that spreads over a range of interfaces/ports in the Interface Group. The IPv6 Gateway increment to spread over a range of interfaces/ports in the Interface Group. The number of interfaces that use the same gateway.
Address Start
Addr Step Addr Step/Port Mask Gw Start
Gw Step Step/X Addr
7-51

All Mesh Test
5. After creating the Interface Groups, click the Traffic Maps tab and create your Traffic Maps. Enter a name for the Traffic Map. 6. Select the Source Interface Group and the Destination Interface Group. 7. Set the frame parameters before running the test. For more details, see Run Parameters on page 7-52.
Run Parameters
The All Mesh test uses the parameters described in Table 7-24 to set the frames.
Table 7-24. Parameter Type DiffServ Option All Mesh Test Frame Parameters Description The protocol type of the traffic frame. The available options are: TCP, UDP, IP. The DSCP value in the IP ToS. See below Table 7-25 for details about the decimal and binary values that identify the service type, when selecting Custom for DiffServOption. Src Port Src Port Incr The protocol source port for the traffic frame. The parameter allows you to choose whether the source port in the traffic frame is to be incremented or not. The options are True, the port value is incremented by 1 and False, no increment. The protocol destination port for the traffic frame. The parameter allows you to choose whether the destination port in the traffic frame is to be incremented or not. The available options are True, the port value is incremented by 1 and False, no increment.
Dst Port Dst Port Incr
Table 7-25. DSCP Default CS1 AF11 AF12 AF13 CS2 AF21 AF22 AF23 CS3
The DSCP Binary and Decimal Values Binary 000000 001000 001010 001100 001110 010000 010010 010100 010110 011000 Decimal 0 8 10 12 14 16 18 20 22 24
7-52

All Mesh Test
Table 7-25. DSCP AF31 AF32 AF33 CS4 AF41 AF42 AF43 CS5 EF CS6 CS7
The DSCP Binary and Decimal Values (Continued) Binary 011010 011100 011110 100000 100010 100100 100110 101000 101110 110000 111000 Decimal 26 28 30 32 34 36 38 40 46 48 56
The test uses the following frame sizes: Standard Automatic Manual
You can set multiple frame sizes per traffic map. The Traffic Map with the longest list of Frame Sizes determines the overall number of Frame Size Iterations. The Traffic Maps that have shorter lists repeat the last value until the Traffic Map with the longest list is done.
Table 7-26. Parameter Load Rate Units Load Rate Start Search Type Binary Min Rate Binary Tolerance Binary Type All Mesh Test Load/Search Parameters Description The available choices are: %Line Rate, Kbps, Mbps, Gbps and Fps. The starting rate for the search used by all search types. The type of the search. The available options are: No Search, Binary Search, and Linear Search. The minimum boundary for the Binary Search algorithm. The threshold/resolution on continuation logic for the Binary Search algorithm. The type of binary search. It determines whether all ports search in lockstep or if they search independently. The options are Linear or Per Port.
7-53

All Mesh Test
All Mesh Test Load/Search Parameters (Continued) Description The load rate increment for the linear/step search. The upper boundary on the linear/step search.
Linear Step Rate Linear Max Rate
Test Setup Parameters
The basic Test Setup Parameters are described in Table 7-27. For the MAC parameters see Configuring MAC Addresses on page 3-19. For the advanced parameters see Advanced Parameters on page 4-7.
Table 7-27. Parameters Test Options Enable ARP Resolution ARP Retries ARP Interval (ms) Enables sending the ARP Request frame to the DUT. If checked, the ARP parameters become available. The number of retries to send ARP Request (default = 3). The time interval, in milliseconds (ms), between sent ARP Requests (default = 3000). Test Setup Parameters Description
ARP/Learn Frequency The frequency at which the ARP Requests/Learning frames are sent. The available options are On Trial, On Iteration, and Never. DHCP Discover/Sec The number of DHCP discoveries per second. This option is enabled when the Interface Type is DHCPv4 or DHCPv6 (default = 10). The number of DHCP releases per second. This option is enabled when the Interface Type is DHCPv4 or DHCPv6 (default = 500). The time period, in hours (hrs), minutes (min), and seconds (s) to wait before aborting a DHCP process. Infinity is defined as 0. This option is enabled when the Interface Type is DHCPv4 or DHCPv6. If Enable ARP Resolution is checked, the check box is available. This option is checked when you are not interested in resolving every ARP before allowing the test to continue.
DHCP Releases/Sec
DHCP Request Timeout
Enable Bit Blasting
7-54

All Mesh Test
Table 7-27. Parameters Map Type
Test Setup Parameters (Continued) Description The One to One and Many to Many options are available. When One-to-One map type is selected, each port in the source interface group sends traffic to one port in the destination interface group. When Many-to-Many map type is selected, each port in the source interface group sends traffic to all the ports in the destination interface groups. The mapping type is applied to every configured traffic map individually.
Trial Duration Parameters Trial Start Pause The time period, in hours (hrs), minutes (min), and seconds (s), to wait before the test starts to transmit frames. The duration of the test, in hours (hrs), minutes (min), and seconds (s), used to calculate the number of frames that need to be transmitted. The time period, in hours (hrs), minutes (min), and seconds (s), to wait after the test ends transmitting frames. The number of trials to send test frames (default = 1).
Trial Search Duration
Trial End Pause
Trials Statistics Parameters Show Per-Flow Statistics
If checked, the per-flow statistics are available.
Pass/Fail Criteria
Table 7-28 lists the pass criteria available for the All Mesh test.
Table 7-28. Parameters Pass Type All Mesh Test Pass/Fail Criteria Description For a specific Traffic Map, each row has its own Pass/ Fail criteria. Only enabled Pass/Fail Traffic Maps are included in Pass/Fail determination. The minimum acceptable line rate value, as a percentage. The minimum acceptable data rate. The units for the data rate.
Line Rate Data Rate Data Units
7-55

VLAN Forwarding Test
Supported Protocols
Supported Protocols
Features Required on Ports Transmit port Receive port
MAC, IP, IPv6, VLANs
Advanced Streams mode Packet Group mode
Results
If Show Per-Flow Statistics is checked, the results include the per flow statistics in order to show flows with or without frame loss. The results include per port statistics if Show Per-Flow Statistics is not checked. The aggregate results always contain the per-traffic statistics. In addition to the standard IxAutomate test results, this test also reports: Minimum Latency Maximum Latency Average Latency

This section covers the following topics: Overview on page 7-56. Test Cycle on page 7-57. Supported Protocols on page 7-58. Traffic Setup: VLAN Parameters on page 7-58. Test Setup: Run Parameters on page 7-58. Pass/Fail Criteria on page 7-59. Results on page 7-60.
Overview
This test determines the DUTs ability to forward VLAN tagged frames over the multiple mesh configurations. The test allows multiple mesh configurations, over the same ports, identified by different VLAN IDs. Frames are initially sent at a user-specified rate, generally the maximum theoretical rate based on the speed of the port. A binary, linear, or fixed search type can be selected to determine the maximum no drop rate. Additionally, the test calculates the minimum, maximum, and average latency. The traffic map used for this test is fully meshed. The test results show the total transmitted and received frames per port, frame loss per port, the maximum throughput, and the minimum, maximum, and average latency rates.
7-56

Note: No more than 4 TOS/DSCP/VLAN Priority values can be configured for a test setup.
ATSS VLAN Forwarding

Ixia Ports DUT
Example of VLAN ID Assignment First VLAN ID : From port: To port: No of VLANs per Port Port 1,1,1 1,1,2 1,1,3 1,1,4 11 1,1,1 1,1,4 2
Assigned VLAN ID 11, 12 11, 12 11, 12 11, 12
Traffic Map Port (VLAN ID) Tx 1,1,1 (11) 1,1,1 (12) 1,1,2 (11) 1,1,2 (12) 1,1,3 (11) 1,1,3 (12) 1,1,4 (11) 1,1,4 (12) Rx 1,1,2 1,1,2 1,1,1 1,1,1 1,1,1 1,1,1 1,1,1 1,1,1 / / / / / / / / 1,1,3 1,1,3 1,1,3 1,1,3 1,1,2 1,1,2 1,1,2 1,1,2 / / / / / / / / 1,1,4 1,1,4 1,1,4 1,1,4 1,1,4 1,1,4 1,1,3 1,1,3
Figure 7-15. ATSS VLAN Forwarding
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test and configuring the ports that you set. Also, if you enable the Send MAC Only option, the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses; otherwise, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports. The binary search algorithm is used to find out and calculate the DUT throughput. Additionally, the latency can be calculated for the test. If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the DUT throughput, the latency, and the frame loss percentage. After all trials for that frame size complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size. The test continues until all trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost packets; at the end, it calculates the latency for all trials. After gathering statistics, it prints the results.
7-57

Supported Protocols
The protocols supported by this test are the following:

Supported Protocols Features Required on Ports Transmit port IP, VLANs Advanced Scheduler mode Receive port Wide Packet Group mode
Traffic Setup: VLAN Parameters
Table 7-29 lists the VLAN parameters available for this test.
Table 7-29. Parameter First VLAN ID No. of VLAN ID per Port VLAN Parameters Description The first VLAN tag to be assigned. The number of VLAN ID per port to be assigned.
For more information about the common run parameters, see Run Parameters on page 7-1. Table 7-30 on page 7-58 lists the run parameters that are different from the standard settings or unique for this test.
Table 7-30. Parameters Addresses per VLAN Per Port Detailed Results Test Setup Parameters Description The number of IP addresses for each VLAN set on each port. If you check this box, the detailed results are available when the test run ends. For example, port 1 is the transmit port and the receiving ports are port 2, port 3, and port 4. If this option is enabled, then for each transmit-receive pair, for each VLAN ID and TOS / DCSP / VLAN Priority values configured, detailed information is available. If this option is not enabled, the results are not available per port, but per VLAN ID and TOS / DCSP / VLAN Priority. Fast Statistics Processing If you check this option, the linear and binary searches and the Pass Criteria are not available; minimum settings are available for obtaining fast statistics. This option is recommended for large port count setups and it ensures faster statistics processing.
7-58

Table 7-30. Parameters Iteration
Test Setup Parameters (Continued) Description Select the algorithm to use in the test: Binary Linear Fixed
No. of Iterations
This parameter is available only for the linear search algorithm and represents the total number of iterations to run the test. It may be necessary to run several iterations in order to test the network characteristics (the default value is 1). This parameter is available only for the binary search algorithm and represents the difference between the real rate transmission, expressed as number of routes, in two consecutive iterations, as compared with the binary resolution value. When the difference between the transmission rate values in two consecutive iterations is smaller than the specified value for the binary resolution, the test stops. This parameter is available only for the binary search algorithm and represents the percentage of total packets allowed to be lost before declaring packet loss. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Resolution
Loss Tolerance
Load Rate
Load is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s) percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which frames are transmitted for the ports.
Min Rate Increment
The minimum rate used for the binary search algorithm Specify the increase value (positive value) or decrease value (negative value) in the transmission rate for each iteration.
For information about the common settings for the ATSS tests, see Setting Up the Tests on page 7-7. Also see Quality of Service (QoS) Settings on page 7-5 for additional information about the frame size settings. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1. For information about other tests in this family, see Advanced Tcl Script Suite (ATSS) on page 7-1.
Pass/Fail Criteria
Table 7-31 lists the pass/fail criteria available for the VLAN Forwarding test.
7-59

Table 7-31. Parameters
VLAN Forwarding Test Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Pass Criteria
% Frame Loss
Latency
Results
In addition to the standard IxAutomate test results, this test also reports (the results are indexed by transmit-receive ports pair, VLAN ID and TOS/DSCP/ VLAN Priority value): Minimum Latency Maximum Latency Average Latency Frame Loss (%)
7-60
Chapter 8:
This chapter describes the tests in the Multi-Port Advanced Test Suite (MATS) in the following topics: Run Parameters on page 8-1. Data Integrity Test on page 8-3. Frame Size Verify Test on page 8-6. Gap Checker on page 8-6. Pattern Verify Test on page 8-7. Port Loss Test on page 8-9. Random Frame Size Test on page 8-10. Sequence Verify Test on page 8-11.
Run Parameters
8-1

Run Parameters
MATS Test Run Parameters Description Configure Pattern: Displays the Configure Pattern window, which enables you to add, modify, and select the data patterns to be used. Data Pattern: Selects the data pattern to be used as a payload. The patterns available are: allOnes allZeroes xAAAA x5555 x7777 xDDDD xF0F0 x0F0F xFF00FF00 x00FF00FF xFFFF0000 x0000FFFF x00010203 x00010002 xFFFEFDFC xFFFFFFFE
Configure Pattern, Data Pattern
Duration
The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The inter-frame gap increment, measured in bits, to be used between iterations. In the Gap Checker test, the inter-frame gap used for the first iteration. The percentage of the Initial Rate used as increments during linear searches. First transmit rate used in the test. Specify this parameter as a percentage of the selected ports maximum theoretical frame rate. The initial rate at which frames are transmitted. This is the percentage of the maximum theoretical frame rate as specified in RFC 1242 used to calculate the initial frame rate. Total number of frames transmitted. The total number of iterations to run the test for.
Gap Increment (bits) IFG Increment (%) Initial Rate
Max Rate (%)
No. of Frames No. of Gap Iterations
8-2

Data Integrity Test
MATS Test Run Parameters (Continued) Description For the Random Frame Size test, the total number of iterations to run the test for. The number of trials to be run. It may be necessary to run several trials of the tests in order to verify consistent results. Indicates the currently selected set of patterns to be applied during the test. The patterns are selected using the Select Pattern button and related dialog. When streams are applied to a number of ports at a time, the start time between ports is staggered by approximately 27ms.
No. of Iterations No. of Trials
Selected Patterns
Staggered Transmit
Data Integrity Test

This test transmits frames that contain a payload consisting of a predefined data pattern, which you can select. The test verifies that the DUT forwards the frames in the correct sequence without corrupting their payloads. For each selected frame size, the test calculates the number of sequence errors (small, big, reverse, and total) and the number of data errors. After the final iteration of the last frame size, the test calculates the aggregate total errors across all frame sizes. This test is similar to the Pattern Verify and Sequence Verify tests. It differs from them in that you can select only a single pattern, you cannot add or modify patterns. Also, because this test uses features available only on the TXS family of load modules, it is very fast. It is especially well suited to large port-count tests. Port mapping is one-to-one. When choosing as Protocol the Layer2-MAC protocol, the generated traffic contains frames that encapsulate packets with valid IP header. You can set both the source IP address and the destination IP address in the IP header. The corresponding parameters are: Tx IP Address parameter allows you to set the source IP address in the IP header. IP Address Mask Width parameter allows you to set the mask width used to increment the IP addresses between ports. Rx IP Address parameter allows you to set the destination IP address in the IP header.
When you start the test, IxAutomate checks the selected ports to confirm that they support the features the test requires; if any do not, the test ends. The test then configures the port features and verifies the link state on each port. If any link is not up, the test ends.
8-3

Data Integrity Test
Starting with the first (smallest) selected frame size, the test sends learn frames (if configured to do so), and then begins transmitting packets containing the selected data pattern. When it has transmitted the selected number of packets, the test collects the statistics on the packets and writes the statistics to the results file. The test repeats this process for each remaining frame size. After the last frame size in the last iteration, the test calculates the statistics for all the frames transmitted and displays the results.
Table 8-2. Parameter Pass Criteria Data Integrity Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Number of errors introduced into payloads of the traffic forwarded by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the numbers of data errors over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest numbers of data errors experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The number of data errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of data errors introduced by the DUT was greater than the number you entered. Sequence Errors Number of sequence errors in the traffic received from the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the numbers of sequence errors over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest numbers of sequence errors experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The number of sequence errors in the traffic received from the DUT was less than or equal to the number you entered. Fail: The number of sequence errors in the traffic received from the DUT exceeded the number you entered.
Data Errors
8-4

Data Integrity Test
Supported Protocols
Features Required on Ports Transmit port Receive port TXS port
MAC, IP
TXS port
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. To determine the features available on your ports, see the Ixia Hardware Guide.
Results
Table 8-3. Result TxFrames RxFrames DataErrors SmallSeqError MATS Data Verify Test Results Description Number of frames transmitted Number of frames received Number of frames received with errors. Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number. BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.
8-5

Frame Size Verify Test
Frame Size Verify Test

This test transmits frames for each frame size within a user-specified frame size range. If frame loss is detected for a particular frame size, that frame size is reported at the end of the test. Successful frame sizes (that is, frame sizes with 0% frame loss) are not reported. Port mapping is one-to-one.
Table 8-4. Parameter Enable Pass Criteria Frame Size Verify Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The DUT lost no frames. Fail: The DUT lost one or more frames.
Supported Protocols
MAC, IP
Packet Streams mode
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. To determine the features available on your ports, see the Ixia Hardware Guide. Capture mode is available on all ports.
Gap Checker
This test transmits frames with incrementing inter-frame gaps (IFG) and reports received frames as a percentage the number of frames received for each IFG. The PHY is used to transmit and receive over a range of IFGs. Port mapping is oneto-one.
8-6

Pattern Verify Test
Gap Checker Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Pass Criteria
% Frame Loss
Supported Protocols
MAC, IP
Packet Streams mode
Pattern Verify Test

This test transmits frames with a unique, predefined set of patterns for all frame sizes and verifies that the payload field of the frames is not corrupted when they were forwarded by the DUT. The verification is performed by capturing a fixed number of frames and matching the pattern of every byte with that of the bytes transmitted for those frames. The Configure Pattern parameters are available in the Test Setup tab (Figure 8-1 on page 8-8). The report for this test consists of a PASS/FAIL status for each pattern type of each frame. Port mapping is one-toone.
8-7

Pattern Verify Test
Figure 8-1.
Pattern Selection Window
To select a data pattern for the test, use the <- or ADD buttons. To remove a data pattern from the test, use the -> or DELETE buttons. Use the Modify button to change the hex value of a data pattern. In addition to the typical System Setup parameters common to most IxAutomate tests, the Pattern Verify test includes a Log Mismatch Pattern Separately option. If you do not check this option and the test encounters a mismatched data pattern during the test, IxAutomate outputs the mismatched pattern to the results file along with other test data. Mismatched data patterns can require a large amount of space to display, resulting in large results files. If you check this option, IxAutomate outputs the mismatched pattern to a separate file.
Table 8-6. Parameter Enable Pass Criteria Pattern Verify Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The DUT forwarded only frames containing the correct pattern. Fail: The DUT forwarded one or more frames with an incorrect pattern.
Supported Protocols
MAC, IP
Packet Streams mode
8-8

Port Loss Test
Port Loss Test

This test determines the maximum number of transmitting ports, at a give line rate, that a DUT can handle simultaneously. Starting at a user defined line rate and a user defined number of port maps, traffic is transmitted out all ports simultaneously. The test iterates, by dropping a port, if the DUT cannot handle the existing traffic load. The test continues to drop ports until the DUT is able to successfully handle all the traffic it receives. Port mapping is one-to-one.
Table 8-7. Parameter Pass Criteria Port Loss Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Number of port pairs remaining. You can select either of two methods to calculate the number of port pairs remaining: Average/Port: The test averages the number of port pairs remaining over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Frame Size: The test selects number of port pairs remaining after transmitting the smallest frame size, then applies the criteria to determine whether a trial passed or failed. Pass: The number of port pairs remaining was greater than or equal to the number you entered. Fail: The number of port pairs remaining was less than the number you entered.
Port Pairs Remaining
Supported Protocols
MAC, IP, IPX
Packet Streams mode
8-9

Random Frame Size Test
Random Frame Size Test

This test determines the capability of a DUT to handle a variety of frame sizes over a period of time with varied data patterns. This test transmits frames with random data in random frame size and reports the loss percentage, total CRC errors received, and a pass/fail status. The minimum and maximum range for random frame sizes may be configured. Port mapping is one-to-one.
Table 8-8. Parameter Pass Criteria Random Frame Size Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered. CRC Errors Number of CRC errors in frames transmitted by the DUT. You can select either of two methods to calculate the number of CRC errors: Average/Port: The test averages the number of CRC errors over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of CRC errors experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The number of CRC errors was less than or equal to the number you entered. Fail: The number of CRC errors exceeded the number you entered.
% Frame Loss
8-10

Sequence Verify Test
Supported Protocols
MAC, IP
Packet Streams mode

This test determines the DUTs ability to ensure that all received packets are transmitted in the same order. This test verifies the packet payload for each frame transmitted with incrementing sequence numbers inserted in the packet as part of the payload. On the receive side, the packets are checked for the incrementing sequence numbers and if any out-of-sequence packets are discovered, a failure condition is notified for those packets. A PASS/FAIL status is reported for each frame. Port mapping is one-to-one.
Table 8-9. Parameter Enable Pass Criteria Sequence Verify Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Pass: The traffic forwarded by the DUT contained no sequence errors. Fail: The traffic forwarded by the DUT contained one or more sequence errors.
Supported Protocols
MAC, IP
Packet Streams mode
8-11

8-12
Chapter 9:

Overview of the IP Multicast (RFC 3918) Test Suite on page 9-1. Setting Up the Tests on page 9-9. Accumulated Test on page 9-16. Aggregated Test on page 9-19. Distributed Test on page 9-24. Group Capacity Test on page 9-27. Group Join Delay Test on page 9-31. Group Leave Delay Test on page 9-36. Latency Test on page 9-40. Mesh Test on page 9-45. Throughput No Drop Rate Test on page 9-49. Mixed Class Throughput Test on page 9-55. Scale Group Test on page 9-60. Tunneling Throughput Test on page 9-64. Burdened Latency Test on page 9-74. Burdened Group Join Delay Test on page 9-78.
This chapter covers the following topics:
Overview of the IP Multicast (RFC 3918) Test Suite

IP multicast is a technology which enables a source to transmit identical data to multiple hosts using a single stream. The immediate benefit of multicast rests in conserving bandwidth.
9-1

In a traditional unicast configuration, if multiple hosts requested the same data from a source, the source would have to send separate, duplicate copies to every host. If there are many hosts, even a low-bandwidth application could consume large amounts of bandwidth. Bandwidth-intensive applications such as streaming video would be impossible on anything but a small scale. Multicast is based on the concepts of groups, sources, and receivers (or hosts). A receiver is a host on a network that has elected to receive some kind of data. A source is a host on a network that is a provider of that data. A group is some number of receivers that share an interest in receiving the same data.
Receiver
Receiver
Source Receiver
Receiver
Figure 9-1.
IP Multicast
A source transmits its data to a particular group. To receive that data, a receiver joins that group. The data from a source to a group is a single stream until it reaches a point on the network where it cannot reach all the receivers over a single path; at that point the stream is duplicated and sent out over the fewest paths possible to the next point in the network. Groups do not restrict receivers to any particular physical locations; they can be located anywhere, as long as the routers between them support IGMP. More details are covered in the following topics: IGMP on page 9-3. MLD on page 9-5. Multicast Addresses on page 9-5. Configuring IP Addresses and IGMP for the IP Multicast Tests on page 9-6. Configuring ARP and IGMP on page 9-7. Selecting a Value for the Group Type Parameter on page 9-8.
9-2

IGMP
Internet Group Management Protocol (IGMP) is the protocol that routers and hosts use to communicate with multicast groups. Hosts join groups by sending IGMP Membership Report messages (usually called Join messages) to the multicast routers on their local LAN. Routers listen for IGMP messages and periodically send queries to find out which groups are active on particular subnets. There are three versions of IGMP; the IP Multicast tests support Version 1 and Version 2: Version 1 on page 9-3. Version 2 on page 9-3. Version 3 on page 9-5.
Version 1
Version 1 includes only two messages: Host Membership Query, a message routers send to confirm that there is at least one host on the subnet that is still interested in receiving traffic sent to a particular group. Host Membership Report, a message hosts send to join a particular group, and periodically re-send to maintain membership in the group.
The format of a Version 1 message is as follows:

0 4 7 Type Unused Group Address 15 Checksum 31
Version
Version is always 1 Type indicates the message type: 1 = Host Membership Query 2 = Host Membership Report
Unused is not used, set to all zeros when sent, and ignored when received. Checksum is a 16-bit one's complement of the one's complement sum of the first eight octets of the IGMP message. Group Address varies according to the message type: In a Host Membership Query message, the Group Address field is set to zeroes when sent, and ignored when received. In a Host Membership Report message, the Group Address field holds the IP host group address of the group being reported.
Version 2
Version 2 includes four messages: Membership Query as in Version 1
9-3

Membership Report as in Version 1 Membership Report, Version 2 Leave Group, a message which a host sends to notify the multicast router that it is leaving a group. This enables the router to stop forwarding traffic for that group immediately if it has no other hosts that belong to that group. In Version 1, a host leaves a group by discontinuing sending membership reports for that group. The router continues to forward the group traffic until a timer expires, even if there are no other hosts on the subnet interested in receiving the traffic. This uses up bandwidth unnecessarily. The format of a Version 2 message is as follows:
0 Type 7 15 Max. Resp. Time Group Address Checksum 31
Type defines the type of the message as follows: 0x11 = Membership Query. There are two sub-types of Membership Query messages: General Query, used to learn which groups have members on an attached network. Group-Specific Query, used to learn if a particular group has any members on an attached network. These two messages are differentiated by the Group Address. 0x16 = Version 2 Membership Report 0x17 = Leave Group 0x12 = Version 1 Membership Report (for backwards-compatibility with IGMP version 1)
Max Response Time is meaningful only in Membership Query messages. This field specifies the maximum time allowed before sending a responding. Units for this field are tenths of a second. For all other messages, it is this field is set to zero by the sender and ignored by receivers. Checksum is the 16-bit one's complement of the one's complement sum of the entire IGMP message (the entire IP payload). For computing the checksum, the checksum field is set to zero. Group Address varies according to the message type: In a Membership Query message, the group address field is set to zero when sending a General Query, and set to the group address being queried when sending a Group-Specific Query. In a Membership Report or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left.
9-4

Version 3
IGMP Version 3 (IGMPv3) adds support for source filtering, which enables a multicast receiver host to signal to a router which groups it wants to receive multicast traffic from, and from which sources this traffic is expected. IGMPv3 receivers signal membership to a multicast host group in the following two modes: INCLUDE mode. In INCLUDE mode, the receiver announces membership to a host group and provides a list of IP addresses (the INCLUDE list) from which it wants to receive traffic. EXCLUDE mode. In EXCLUDE mode, the receiver announces membership to a host group and provides a list of IP addresses (the EXCLUDE list) from which it does not want to receive traffic. This indicates that the host wants to receive traffic only from other sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, a host expresses EXCLUDE mode membership by providing an empty EXCLUDE list.
MLD
Multicast Listener Discovery (MLD) is a protocol that enables IPv6 routers to discover the presence of multicast listeners (nodes that want to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to neighboring nodes. This information is then provided to whichever multicast routing protocol is being used by the router, in order to ensure that multicast packets are delivered to all links where there are interested receivers. Version 2 of MLD includes support for source filtering. MLDv2 is designed to be interoperable with MLDv1.
Multicast Addresses
A multicast address is an address to which receivers send Join requests to receive traffic for a particular group. The Internet Assigned Numbers Authority (IANA) has allocated the IP class D address space for multicast addresses. This means that multicast addresses must be within the range 224.0.0.0 to 239.255.255.255. Within this range, there are certain addresses that are used by other applications or have special significance, and so cannot be used for IP multicast. No multicast router should forward a packet with a reserved address. The full list of these addresses is available at: http://www.iana.org/assignments/multicast-addresses. More details are covered in the following topics: Globally Scoped and Limited Scope Addresses on page 9-5. Addresses Reserved for Network Protocols on page 9-6.
Globally Scoped and Limited Scope Addresses

Globally Scoped Addresses are within the range of 224.0.1.0 through 238.255.255.255. These addresses can be used to multicast data between organizations and across the Internet. However, within this range, IANA has reserved
9-5

some addresses for Internet-wide applications. For example, Network Time Protocol (NTP) uses 224.0.1.1. Limited Scope or Administratively Scoped Addresses are within the range of 239.0.0.0 through 239.255.255.255. These addresses are restricted to belonging to a local group or organization. Routers typically filter these addresses to prevent multicast traffic in this address range from flowing outside an Autonomous System (AS) or other user-defined domain.
Addresses Reserved for Network Protocols

Within the address range allocated for IP multicast, the certain addresses are commonly used by network protocols for the purposes of discovering routers and exchanging information. Table 9-1 lists some of the more commonly-used addresses:
Table 9-1. Address 224.0.0.1 224.0.0.2 224.0.0.5 224.0.0.6 224.0.0.12 Well-Known Local Link Addresses Description All systems on this subnet All routers on this subnet OSPF routers OSPF Designated Routers DHCP Server/Relay Agent
Configuring IP Addresses and IGMP for the IP Multicast Tests
You configure IP addresses for the IP multicast tests in a similar manner as the other IxAutomate tests (see Configuring IP Addresses on page 3-25). However, the IP multicast tests require some additional steps to accommodate the multicast group addresses and IGMP messages. On the DUT: Enable both IP forwarding and IGMP. Enable and configure one of the following IP multicast protocols: DVMRP, PIM-SM or PIM-DM.
On the Ixia chassis: Specify unicast addresses for the Ixia ports and their corresponding DUT ports. These are controlled by the Source address of first port, Gateway/ DUT, and IP Address Octet Increment parameters. Specify the addresses of the IP multicast groups that the Ixia ports are to join as IP multicast clients. The tests increment the group address and assign the incremented addresses to the Ixia ports. These are controlled by the First Group Address and Total Groups parameters.
When a test begins, the Ixia destination or receive ports join their assigned groups by sending IGMP Join messages to the DUT. The DUT stores the IGMP
9-6

group addresses for each port in its IGMP table. After sending the Join messages, the transmit port sends validation traffic (IP frames) addressed to the groups that the receive ports joined. The DUT should forward the multicast group traffic to the appropriate receive ports. Whether you decide to use the tests default IP addressing scheme or your own, make sure that you configure the DUT ports to match the addresses the test expects. Figure 9-2 shows how the test assigns IP unicast and multicast addresses using the default values. Port 1 is the transmit port and ports 2, 3, and 4 are receive ports.
Source Address of First Port: 192.18.1.100 Gateway/DUT: 198.18.1.1 IP Address Octet Increm ent: 3 Increm ent Gateway IP Address: Enabled (checked) ----------------------------------------------------------------------First Group Address: 224.0.1.1 Total Group Addresses: 30 Group Type: Distributed DUT
Ixia card
Port 1
IP: 192.18.1.100
192.18.1.1
Port 1
Port 2
IP: 192.18.2.100
IGMP Join
192.18.2.1
Port 2
Joins groups 224.0.1.1 to 224.0.1.10 IP: 192.18.3.100 IGMP Join 192.18.3.1 Port 3
Port 3
Joins groups 224.0.1.11 to 224.0.1.20 IP: 192.18.4.100 IGMP Join 192.18.4.1
Port 4
Port 4
Joins groups 224.0.1.21 to 224.0.1.30
Figure 9-2.
IP Address Assignment on Ixia and DUT Ports
Configuring ARP and IGMP
The ARP and IGMP parameters allow you to set how the test sends address learning and IP multicast commands. Figure 9-3 on page 9-8 shows the Learning Frames pane. When a test begins, the Ixia receive ports join their assigned groups by sending IGMP Join messages to the DUT. The DUT stores the IGMP group addresses for each port in its IGMP table. The available Multicast Parameters are described in Run Parameters on page 913.
9-7

Frequency: Defines how often the test sends IP multicast Join (and optionally, ARP) commands. If you select Once per Test, the test sends the commands only once at the beginning of the test. If you select Once per Frame Size, the test sends the commands at the beginning of the first iteration for each frame size. If you select On Trial, the test sends the commands at the beginning of each trial. If you select On Iteration, the test sends the commands at the beginning of each iteration.
Enable Send ARP/ Neighbor Discovery: If you check this box, the test sends ARP commands at the same frequency as it sends IGMP messages. No. of Frames: Number of ARP and IGMP frames transmitted. Rate: Rate at which the test sends ARP and IGMP frames.
Figure 9-3.
Learning Frames Pane
Selecting a Value for the Group Type Parameter
Many of the IP multicast tests include the Group Type parameter. This parameter determines how the test allocates the multicast group addresses among the ports used in the test. For most of the tests, Group Type can have one of two values: Distributed or Accumulated. For the Distributed and Accumulated tests, the only value is Distributed. The difference between Distributed and Accumulated rests in how they allocate the multicast addresses among the receive ports: Distributed: If you select Distributed, the test divides the total number of multicast groups by the number of receive ports. If the groups do not divide evenly among the ports, the test allocates enough additional groups to the first receive port so that the remainder divide evenly among the remaining ports. Accumulated: If you select Accumulated, the test applies the total number of groups to each receive port, meaning that each receive port joins every group.
Table 9-2 shows two examples of how the test allocates multicast groups among receive ports based on the value of Group Type.
Table 9-2. Effect of Group Type Parameter on Group Distribution Group Type = Distributed 12 Groups, Receive port 1: 4 groups 3 Receive ports Receive port 2: 4 groups Receive port 3: 4 groups 13 Groups, Receive port 1: 5 groups 3 Receive ports Receive port 2: 4 groups Receive port 3: 4 groups Group Type = Accumulated Receive port 1: 12 groups Receive port 2: 12 groups Receive port 3: 12 groups Receive port 1: 13 groups Receive port 2: 13 groups Receive port 3: 13 groups
9-8


Most of the IP multicast test parameters are common to all the tests, and work the same way on all of them. The description of each test includes a description of the parameters, which are unique for each test. The common run parameters for the IP Multicast tests are described below (see Run Parameters on page 9-13). The other parameters are: Protocols: All the multicast tests use IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Frame Sizes: All the multicast tests allow you to select and test multiple frame sizes. For information about frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: Most of the tests use one-to-many traffic maps, as described in Setting Up the Traffic Map on page 3-11. In addition, you can configure Tx (Untagged, VLAN, or Q-in-Q) and Rx (Untagged or VLAN) traffic. Only for Group Join and Group Leave Delay test (Group Join Delay Test on page 9-31) you can configure Q-in-Q Rx traffic. The Burdened Latency Test on page 9-74 test and the Burdened Group Join Delay Test on page 9-78 use two traffic maps: a one-to-many traffic map for multicast traffic as in the other tests (it is a manual map) and a many-to-many traffic map for the unicast traffic as burdening traffic (it has to be fully meshed, so this is an automatic map). VLANs: For the parameters common for most of the tests in IxAutomate, see Setting the VLAN Parameters on page 3-42 and How IxAutomate Assigns VLAN IDs on page 3-43.
Note: You can use the Advanced Test Parameter Verify All ARP Replies to confirm that all the addresses that receive ARPs reply to them. See Advanced Parameters on page 4-7.
For more details, refer to the following topics: Stacked VLAN (Q in Q) on page 9-9. Testing with Multiple Traffic Maps on page 9-10. DUT Setup on page 9-11. Run Parameters on page 9-13.
Stacked VLAN (Q in Q)
When using both automatic or manual traffic map, the VLANs parameters may be used to enable the outer VLAN tag (Enable 802.1q Tag) and the inner VLAN tag (Enable stacked VLAN (Q in Q)): If Automatic traffic map is selected:
9-9

For the outer VLAN, you can set the First VLAN ID, First VLAN TPID, and the Increment VLAN ID (these are available in the Traffic Setup window, Frame Data section); For the stacked VLAN, you can define the First Inner VLAN ID, First Inner VLAN TPID, and the Increment Inner VLAN ID (these are available in the Traffic Setup window, Frame Data section).
If Manual traffic map is selected: For the outer VLAN, you can set the VLAN ID, VLAN TPID, and the No. of Addresses. For the stacked VLAN, you can define the Inner VLAN ID, Inner VLAN TPID (it is available in the Port Names window, which opens if clicking the Per Port Settings button).
Inner VLAN Parameters Description Applies the inner VLAN settings. The first inner VLAN tag to be assigned If you check this box, the test increments the inner VLAN tag assigned to each port. If you do not check this box, traffic from every port has the same inner VLAN ID.
Enable stacked VLAN (Q in Q) First Inner VLAN ID Increment Inner VLAN ID
Testing with Multiple Traffic Maps
If you want to increase the traffic load applied to a DUT within a given amount of time, you can use multiple traffic maps. For example, most of the IP multicast tests use a one-to-many map. In a standard test scenario, you select one Ixia port to be the transmit port and some number of receive ports. If you set Max Rate to 100%, the total amount traffic that is generated during the test is determined by the speed of the transmit port and the Duration. To increase the amount of traffic, set the Traffic Map parameter to Manual, select a transmit port and its receive ports, then select an additional transmit port and its receive ports (see To Configure a Manual Traffic Map: on page 3-17 for a step-by-step procedure). If you use multiple traffic maps, the test continues the IP addressing from the first map into subsequent traffic maps. However, the test applies the Total Group Address parameter separately to each. For example, you could use the default IP address parameters,
Source Address of First Port: Gateway/DUT: IP Address Octet Increment: Increment Gateway IP Address: 192.18.1.100 198.18.1.1 3 Enabled (checked)
9-10

First Group Address: Total Group Addresses:
224.0.1.1 30
to create two traffic maps, each containing one transmit port and three receive ports. Figure 9-3 shows how the test would assign IP addresses if the Group Type was set to Distributed.
Ixia card 1 DUT
Port 1 Transmit Port 2 Receive
IP: 192.18.1.100
192.18.1.1
Port 1
First traffic map 1,1,1 1,1,2 1,1,3 1,1,4
IP: 192.18.2.100 Joins groups 224.0.1.1 to 224.0.1.10 IP: 192.18.3.100 Joins groups 224.0.1.11 to 224.0.1.20 IP: 192.18.4.100 Joins groups 224.0.1.21 to 224.0.1.30
192.18.2.1
Port 2
Port 3 Receive
192.18.3.1
Port 3
Port 4 Receive
192.18.4.1
Port 4
Ixia card 2
Port 1 Transmit Port 2 Receive
IP: 192.18.5.100
192.18.5.1
Port 5
IP: 192.18.6.100 Joins groups 224.0.1.1 to 224.0.1.10 IP: 192.18.7.100 Joins groups 224.0.1.11 to 224.0.1.20 IP: 192.18.8.100 Joins groups 224.0.1.21 to 224.0.1.30
192.18.6.1
Second traffic map 1,2,1 1,2,2 1,2,3 1,2,4
Port 6
Port 3 Receive
192.18.7.1
Port 7
Port 4 Receive
192.18.8.1
Port 8
Figure 9-4.
Addressing Using Multiple Traffic Maps
Note: If you are testing multiple DUTs simultaneously, you must use identical traffic maps for each DUT.
DUT Setup
To configure the DUT for the IP multicast tests, use its management software to: Configure IP addresses on the interfaces (ports) that you want to use Enable multicast on the DUT Enable IGMP on the DUT and, if necessary, on the specific interfaces that you want to use
Sample Commands
Table 9-4 lists the basic Cisco IOS commands for configuring multicast on Cisco routers. Table 9-5 lists the equivalent commands for a Juniper Networks router.
9-11

Caution: Please take all appropriate precautions when using these sample commands. If you are unsure as to how to use the commands or as to their possible effect on your DUT or network, please seek appropriate assistance. Ixia cannot be responsible for any damage that use of the commands causes to your DUT or network.
Cisco
Table 9-4. Cisco IOS Commands for Multicast Tests Description
Command String Global Commands: configure terminal ip multicast-routing Port Commands: interface fastEthernet 0/0 Choose one of the following: ip pim sparse-mode or ip pim sparse-dense-mode or ip dvmrp unicast-routing sho ip igmp groups
Enters global configuration mode from the terminal. Enables multicast globally on the router.
Selects Fast Ethernet interface 0/0 for configuration.
Enables an IGMP routing protocol on the interface.
Displays the current status of IP multicast on the router. You can use this command while you run the multicast tests to watch the progress of the tests.
sho ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime 230.100.100.70 FastEthernet0/0 00:00:16 230.100.100.71 FastEthernet0/0 00:00:16 230.100.100.68 FastEthernet0/0 00:00:16 230.100.100.69 FastEthernet0/0 00:00:16 230.100.100.66 FastEthernet0/0 00:00:16
Expires 00:02:43 00:02:43 00:02:43 00:02:43 00:02:43
Last Reporter 10.0.9.2 10.0.9.2 10.0.9.2 10.0.9.2 10.0.9.2
Juniper Networks
Table 9-5. Juniper Networks Commands for Multicast Tests Description Enters configuration mode. Enters IGMP PIM configuration mode.
Command String configure edit protocols pim
9-12

Table 9-5.
Juniper Networks Commands for Multicast Tests (Continued) Description Enables PIM on Fast Ethernet interface 0/2/1. Configures the interface to use IGMP Version 2 messages. Configures the interface to use sparse mode PIM. Saves the configuration to the database and causes it to take effect. Displays the current IP multicast groups on the router. You can use this command while you run the multicast tests to watch the progress of the tests. Source 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Last Reported 192.168.3.13 192.168.5.38 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 Timeout 231 235 0 0 0 0 0 0 0 0
Command String set interface fe-0/2/1 enable set interface fe-0/2/1 version 2 set interface fe-0/2/1 mode sparse commit run show igmp group
Interface fxp0.0 fxp0.0 local local local local local local local local
Group 224.0.0.2 224.0.1.22 224.0.0.2 224.0.0.4 224.0.0.5 224.0.0.6 224.0.0.9 224.0.0.13 224.0.0.22 224.2.127.254
Run Parameters
Table 9-6 lists the common run parameters for the IP Multicast tests.
Table 9-6. Parameter Duration IP Multicast Tests - Test Setup Common Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted.
Test Parameters No. of Trials No. of Iterations Burst Size (# of frames) Select how many times you want to test each frame size. Specify the number of times the test increments or decrements the frame rate. It allows you to set the number of frames transmitted per burst. For the traffic transmitted in bursts, set: the inter-packet gap to minimum (it corresponds to 100% rate) the inter-burst gap and inter-stream gap so as the traffic sum be equal to the rate specified by the user.
9-13

IP Multicast Tests - Test Setup Common Parameters (Continued) Description The percentage of total packets allowed to be lost before declaring packet loss. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Loss Tolerance (%)
Latency Type
Selects the method used to calculate latency: Cut Through: Delay between the time the first bit of the test frame leaves the Ixia TX port and the time it arrives on the Ixia RX port. Cut Through is normally used with switches and other devices that operate using packet header information. 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: Delay between the time the last bit of the test frame leaves the Ixia TX port and the time its first bit arrives on the Ixia RX port. Store and forward latency is calculated by first determining the Cut Through delay and then substracting the frame length time. Store and Forward is normally used with routers and other devices that operate on the contents of the entire packet. The last transmitted data bit is usually the end of the FCS or CRC, and the first data bit received is as described above for Cut Through.
Calibrate Latency
If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10.
Multicast Parameters First Group Address Join/Leave Rate (fps) Total Group Addresses IP address of the first multicast group. The number of frames per second sent for the Join/ Leave messages. The number of group addresses to be assigned to each port. During the test, each port joins this number of groups starting with the group specified by the First Group Address parameter. The number of addresses to add or subtract (specify a negative number) to the Total Group Addresses for each iteration. The IGMP version to use: 1, 2 or 3. The MLD version to use: 1 or 2. When the IGMP version parameter is set to 1, you can choose a value for the timeout multicast group.
Increment Addr
IGMP Version MLD Version V1 Group Time Out
9-14

IP Multicast Tests - Test Setup Common Parameters (Continued) Description When the IGMP version parameter is set to 3, you can choose one of the available modes for the receivers to signal membership to a multicast host group: Include Exclude
V3 Message Type
Enable Leave Group
If you check this box, the hosts simulated by the Ixia port send IGMP Leave Group messages to the DUT at the end of the test. Sets the IP header Send Router Alert bit in messages. Determines how addresses are allocated among ports: If you select Accumulated, the same addresses are duplicated on each port. If you select Distributed, the total number of addresses is divided among the ports.
Enable Router Alert Group Type
Send Join Frames Duration(s)
Configure the wait time for sending Join frames. If this is set to 0, the send time is calculated as (No.of Learning Frames * No.of Addresses) / (Join/Leave Rate).
Load Rate Payload Kbits/Second (ATM interfaces only) Load is applied to the DUT by transmitting at a rate of kilobits per second (Kb/s), measured using the bits in the payload portion of the ATM cell. Initial: Specify the rate at which the test transmits for the first iteration. Increment: Specify the increase (positive value) or decrease (negative value) in the transmit rate for each new iteration. Max Rate (%) Load is applied to the DUT by transmitting frames at a percentage of the maximum frame rate. Initial: The starting rate at which frames are transmitted. Specify this value as a percentage of the ports maximum theoretical frame rate. Use caution when specifying low Initial Rates; the test can become less accurate if the frame rate approaches 1 f/s. Increment: Specify the percentage point increase (positive value) or decrease (negative value) in the transmit rate for each new iteration.
9-15

Accumulated Test
IP Multicast Tests - Test Setup Common Parameters (Continued) Description Load is applied to the DUT by transmitting frames in terms of frames per second. Initial: Initial number of frames per second transmitted. Use caution when specifying low Initial Rates; the test can become less accurate if the frame rate approaches 1 f/s. Increment: Specify the increase (positive value) or decrease (negative value) in the number of frames per second transmitted for each new iteration.
Frames / Second
Join Delay Calculation Join New Group Join Existing Group Initial Join Wait Time It calculates the delay when joining a group that does not exist in the DUTs forwarding table. It calculates the delay when joining an existing group for which the DUT already forwards traffic. The amount of time to wait for the initial join messages.
Load Rate for Burden Ports Load Rate (%) Load is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s) percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which unicast frames are transmitted for the burden ports. Increment Specify the increase value (positive value) or decrease value (negative value) in the transmission rate for each iteration, for the burden ports.
Accumulated Test
This section covers the following topics: Overview on page 9-16. Test Cycle on page 9-17. Supported Protocols on page 9-18. Test Setup: Run Parameters on page 9-18. Pass Criteria on page 9-18. Test Results on page 9-18.
Overview
This test determines the DUT's throughput when clients join a large number of groups at a specified rate. The test stresses the DUT by forcing it to rapidly update its IGMP group cache and then forward traffic to all the groups. This test
9-16

Accumulated Test
uses a one-to-many traffic mapping and requires at least three ports; namely one to transmit and two to receive. This test functions in a similar way to the Distributed Test on page 9-24, but differs from it in that each receive port joins every group, resulting in same multicast traffic going out multiple ports.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the range of groups. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. Each receive port joins the same groups. After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. Each receive port should receive all the traffic, because every port belongs to the same groups. After the test has transmitted all the traffic, if you check Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Rate. If you specified more than one iteration, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. If you specify a negative value for Increment, the test behaves in a similar way, but decreases the port speed. If you specify a combination of No. of Iterations and Increment values that causes the transmit rate to drop to 1 f/s or less, the test stops for that frame size. If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations.
9-17

Accumulated Test
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3 Packet Streams mode Receive port Capture mode
For more information about the common run parameters, see Run Parameters on page 9-13. For information about the common settings for the IP Multicast tests, see Setting Up the Tests on page 9-9. For information about other tests in this family, see IP Multicast (RFC 3918) Test Suite on page 9-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass Criteria
Table 9-7 lists the pass criteria for this test.

Table 9-7. Parameter Pass Criteria Pass Criteria If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered. IP Multicast Accumulated Test - Pass Criteria Description
% Frame Loss
Test Results
The following is an example of the results for an Accumulated test run with the settings listed in Table 9-8.
9-18

Aggregated Test
Table 9-8. Frame Size: Duration: Max Rate: Group Type: Total Group Addresses:
IP Multicast Accumulated Test Results Sample 64 bytes 10 seconds 100 Accumulated 10 224.0.1.1
Address of First Group
Transmit / receive port pair. TX: Transmit port RX: Receive port
TxFrames/RxPort lists the number of frames transmitted to the multicast groups associated with this receive port.
First Group and Last Group are the IP addresses of the first and last multicast groups this receive port joined
IP Multicast Accumulated - IP --> Framesize: 64 TX RX TxFrames/RxPort RxFrames Loss(%) FirstGroup LastGroup #Groups ******************************************************************************************************** 1.1.1 1.1.2 1488100 1487176 0.062 224.0.1.1 224.0.1.10 10 1.1.1 1.1.3 1488100 1487177 0.062 224.0.1.1 224.0.1.10 10 1.1.1 1.1.4 1488100 1487173 0.062 224.0.1.1 224.0.1.10 10 ******************************************************************************************************** %MaxRate = 100
%MaxRate is the value configured for the Max Rate parameter.
RxFrames lists the number of frames that the DUT was able to forward from the transmit port to the receive port.
Loss(%) is the percentage of frames that the DUT failed to forward from the transmit port to the receive port.
#Groups is the number of multicast groups that this receive port joined.
Aggregated Test
Overview
This test measures a DUTs ability to maintain IP multicast traffic throughput when a fixed number of clients are re-distributed among fewer subnets. To simulate this, the test reduces the number of ports to which it transmits while keeping the number of clients fixed.
9-19

Aggregated Test
You can allocate group addresses using either the Distributed or Accumulated options for the Group Type parameter (see Selecting a Value for the Group Type Parameter on page 9-8). This test uses a one-to-many traffic mapping and requires at least four ports; namely one to transmit and three to receive. Because this test must drop a port and then run another iteration, you should not run this test with less than two iterations (the default value). You should also ensure that the number of receive ports exceeds the number of iterations by at least one.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames so the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group and the beginning of the range of groups. Total Group Addresses defines the width of the range and the remaining addresses. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. For example, by using the default values for both parameters (First Group Address = 224.0.1.1 and Total Group Addresses = 9), the ports try to join ten groups, with addresses 224.0.1.1 through 224.0.1.9. The tests allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports. If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. After the test has transmitted all the traffic, if you check Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Rate. For the next iteration, the test reduces the number of receive ports by dropping the highest-numbered port from the traffic map. For example, if the receive ports being used are 1,2,1, 1,3,2, and 1,2,3, the test drops port 1,3,2.
9-20

Aggregated Test
If Group Type was set to Distributed, the test re-allocates the dropped ports addresses among the remaining ports. The test then retransmits the same amount of traffic at the same rate to all the same addresses as in the previous iteration. If you specified more than two iterations, the test again drops the current highestnumbered receive port and then repeats. If the dropped port was the last remaining port, the test ends for that frame size. If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations.
Supported Protocols

Pass Criteria
9-21

Aggregated Test
IP Multicast Aggregated Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Pass Criteria
% Frame Loss
Leaked Frames
Number of frames forwarded incorrectly by the DUT. Pass: The number of frames mis-routed by the DUT was less than or equal to the number you entered. Fail: The number of frames mis-routed by the DUT was greater than the number you entered.
9-22

Aggregated Test
Test Results
The following are examples of the results for the Aggregated test run with the Group Type parameter set to each of its two values, Accumulated and Distributed, and to the values listed in Table 9-10.
Table 9-10. Frame Size: Duration: Max Rate Total Group Addresses: Address of First Group IP Multicast Aggregated Test Results Sample 128 bytes 10 seconds 100 9 224.0.1.1
For more details, refer to the following topics: Results for Accumulated Group Type on page 9-23. Results for Distributed Group Type on page 9-24.
Results for Accumulated Group Type

Transmit / receive port pair. TX: Transmit port RX: Receive port TxFrames/RxPort lists the number of frames transmitted to the multicast groups associated with this receive port. First Group and Last Group are the IP addresses of the first and last multicast groups this receive port joined
IP Multicast Aggregated - IP --> Framesize: 128 TX RX TxFrames/RxPort RxFrames Loss(%) FirstGroup LastGroup #Groups ******************************************************************************************************** 1.1.1 1.1.2 1689120 1688662 0.027 224.0.1.1 224.0.1.9 9 1.1.1 1.1.3 1689120 1688574 0.032 224.0.1.1 224.0.1.9 9 1.1.1 1.1.4 1689120 1688662 0.027 224.0.1.1 224.0.1.9 9 ******************************************************************************************************** # Ports = 3 %MaxRate = 100
# Ports is the number of ports used in the test. %MaxRate is the value configured for the Max Rate parameter.
9-23

Distributed Test
Results for Distributed Group Type

Transmit / receive port pair. TX: Transmit port RX: Receive port TxFrames/RxPort lists the number of frames transmitted to the multicast groups. First Group and Last Group are the IP addresses of the first and last multicast groups this receive port joined
IP Multicast Aggregated - IP --> Framesize: 128 TX RX TxFrames/RxPort RxFrames Loss(%) FirstGroup LastGroup #Groups ******************************************************************************************************** 1.1.1 1.1.2 563040 563018 0.004 224.0.1.1 224.0.1.3 3 1.1.1 1.1.3 563040 562923 0.021 224.0.1.4 224.0.1.6 3 1.1.1 1.1.4 563040 562844 0.035 224.0.1.7 224.0.1.9 3 ******************************************************************************************************** # Ports = 3 %MaxRate = 100 RxFrames lists the number of Loss(%) is the percentage #Groups is the number TotalTxFrames = 1689120 frames that the DUT was able of frames that the DUT failed of multicast groups that TotalRxFrames = 1688785 TotalLoss(%) = 0.020 to forward from the transmit to forward from the transmit this receive port joined.
port to the receive port.
port to the receive port.
#Ports is the number of receive ports used in the test. %MaxRate is the value configured for the Max Rate parameter. TotalTxFrames is the total number of frames transmitted to all ports. TotalRxFrames is the total number of frames received on all ports. Total Loss(%) is the percentage of all frames transmitted that the DUT failed to forward.
Distributed Test
Overview
This test determines the DUTs ability to forward traffic to the correct multicast clients on a per-port basis. In this test, each receive port joins a different set of multicast groups. The test sends validation traffic to all the groups to calculate the throughput. This test functions in a similar way to the Accumulated test, but differs from it in that each receive port joins a different set of groups, resulting in different streams of multicast traffic going out different ports of the DUT. If any of the receive ports receives a frame addressed to a group it did not join, that indicates that the DUT is mis-routing or leaking frames.
9-24

Distributed Test
This test uses a one-to-many traffic mapping and requires at least three ports; namely one to transmit and two to receive.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. After the test has transmitted all the traffic, if you checked Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Rate. If you specified more than one iteration, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. If you specify a combination of No. of Iterations and Increment values that causes the transmit rate to drop to 1 f/s or less, the test stops for that frame size. If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations.
Supported Protocols

9-25

Distributed Test
Pass Criteria

Table 9-11. Parameter Pass Criteria IP Multicast Distributed Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Test Results
The following is an example of the results for the Distributed test run with the values listed in Table 9-12.
Table 9-12. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Address of First Group IP Multicast Distributed Test Results Sample 512 bytes 20 seconds 100 Distributed 9 224.0.1.1
9-26

Group Capacity Test
TxFrames/RxPort lists the number of frames transmitted to this receive port. RxFrames lists the number of frames that the DUT was able to forward from the transmit port to the multicast groups associated with this receive port.
IP Multicast Distributed - IP --> Framesize: 512 TX RX TxFrames/RxPortRxFrames Loss(%) LeakedFrames FirstGroup LastGroup #Groups *********************************************************************************************************** 1.1.1 1.1.2 156636 156636 0.000 0 224.0.1.1 224.0.1.3 3 1.1.1 1.1.3 156636 156630 0.004 0 224.0.1.4 224.0.1.6 3 1.1.1 1.1.4 156636 156590 0.029 0 224.0.1.7 224.0.1.9 3 *********************************************************************************************************** %MaxRate = 100 TotalTxFrames = 469908 Loss(%) is the Leaked Frames is the #Groups is the number of TotalRxFrames = 469856 percentage of frames number of frames the multicast groups that this TotalLeaked = 0 that the DUT failed to DUT sent to this port receive port joined. TotalLoss(%) = 0.011 forward from the transmit which no multicast client
port to the receive port. %MaxRate is the value configured for the Max Rate parameter. TotalTxFrames is the total number of frames transmitted to all ports. TotalRxFrames is the total number of frames received on all ports. TotalLeaked is the total number of all frames the DUT forwarded to the wrong multicast groups. Total Loss(%) is the percentage of all frames transmitted that the DUT failed to forward.
on the port requested First Group and Last Group are the IP addresses of the first and last multicast groups this receive port joined
Group Capacity Test

Overview
This tests determines the maximum number of multicast groups that a DUT can register and to which it can forward multicast frames. This test requires at least two ports; namely one to transmit and one to receive, and uses a one-to-many traffic mapping.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters.
9-27

Group Capacity Test
If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group and the beginning of the range of groups. Total Group Addresses defines the width of the range and the remaining addresses. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. For example, using the default values for both parameters (First Group Address = 224.0.1.1 and Total Group Addresses = 20), the ports try to join twenty groups, with addresses 224.0.1.1 through 224.0.1.20. The tests allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports. If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. After the test transmits all the traffic, the receive ports send Leave Group messages to the DUT at the rate specified for Rate; the received traffic is analyzed and if all the multicast groups have received at least one frame, it means that the DUTs group capacity has not been exceeded. The test continues with new iterations, using more groups, until the DUTs group capacity is exceeded. The Increment Addr parameter determines the number of additional groups for the next iterations. To calculate the new number of groups, the test adds the value of Increment Addr to the number of groups in the previous iteration. As with the previous iteration, the test allocates the groups to the ports according to the Group Type parameter. The test continues until the DUT fails to forward frames to at least one of the multicast group addresses. At this time, the group capacity of the DUT has been exceeded and the previous iteration gives the actual DUT group capacity. If you specified more than one trial for No. of Trials and more frame sizes, the test repeats until all the trials and frame sizes complete.
Supported Protocols
9-28

Group Capacity Test
Supported Protocols
IP, IPv6, VLANs, IGMPv1,2,3
Packet Streams mode
Table 9-13. Parameter Join/Leave Wait Time IP Multicast Group Capacity Test - Run Parameters Description The amount of time to wait for the group join or group leave messages to be processed by the DUT. For an accurate result, it is recommended to run first the Group Join Delay test and then to use the value previously determined for this test.
Pass Criteria

Table 9-14. Parameter Pass Criteria IP Multicast Group Capacity Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Number of multicast groups the DUT should be able to register. Pass: The number of groups registered by the DUT was greater than or equal to the number you entered. Fail: The number of groups registered by the DUT was less than the number you entered.
Group Capacity
9-29

Group Capacity Test
Test Results
The following is an example of the results for the Group Capacity test run with the values listed in Table 9-15.
Table 9-15. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Increment Addr.: Address of First Group IP Multicast Group Capacity Test Results Sample 1024 bytes 10 seconds 100 Accumulated 100 50 224.0.1.1
TxFrames/RxPort lists the number of frames transmitted to this receive port. RxFrames lists the number of frames that the DUT was able to forward from the transmit port to the receive port.
IP Multicast Group Capacity - Accumulated - IP --> Framesize: 1024 TX RX TxFrames/RxPortRxFrames Loss(%) FirstGroup LastGroup #Groups ********************************************************************************************* 1.1.1 1.1.2 10000 9978 0.220 224.0.1.1 224.0.1.250 250 1.1.1 1.1.3 10000 9978 0.220 224.0.1.1 224.0.1.250 250 1.1.1 1.1.4 10000 9978 0.220 224.0.1.1 224.0.1.250 250 ********************************************************************************************* %MaxRate = 10 TotalGroupAdd = 250
First Group and Last Group are the IP addresses of the first and last multicast groups this receive port joined
%MaxRate is the value configured for the Max Rate parameter. TotalGroupAdd is the total number of multicast group addresses configured in the test
9-30

Group Join Delay Test

Overview
This test determines how long it takes a DUT to register multicast clients to a new group or to a group that already exists in the DUTs forwarding table. The test measures the elapsed time between the time a DUT receives a group of IGMP Join requests and the time the multicast clients begin receiving traffic for the groups they have joined. The test can optionally increase or decrease the frame rate to record how different frame rates affect the delay between joining a group and receiving traffic. This test requires a minimum of four ports; namely one to transmit, at least two to receive, and one to act as the timing port that allows the test to derive timing information for the validation traffic. This test uses a one-to-many mapping.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. For example, using the default values for both parameters (First Group Address = 224.0.1.1 and Total Group Addresses = 9), the ports try to join ten groups, with addresses 224.0.1.1 through 224.0.1.9. The test allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports.
9-31

If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
For the Group Type set to Accumulated, you can choose the join delay calculation method: Join Existing Group it calculates the delay to join an existing group for which the DUT already forwards traffic. Join New Group it calculates the delay to join a group that does not exist in the DUT forwarding table.
If you enable the Send Extra Join Frames function, extra join frames are sent in addition to the join frames that are sent at the beginning of the test. The number of frames, the start address, and the number of addresses are configurable. The number of extra joins represents the number of joins sent for each extra group address. The extra join frames are sent before group joins for the multicast addresses used in the test so as not to interfere with the actual delay measurement for these group addresses. Nonetheless, there is no restriction to setting the extra group addresses. If at least one of the multicast addresses used in the test is used for extra joins, the measurement of the delay will be incorrect, as the group will be joined earlier. After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. Each receive port should receive only traffic intended for the groups they joined. If any of the receive ports receives a frame addressed to a group it did not join, this indicates that the DUT is misrouting or leaking frames. If you specified more than one iteration, the test changes the frame rate based on the value for Increment, and repeats. If you specified more than one iteration, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. At the end of each iteration, the receive ports send Leave Group messages to the DUT at the rate specified for Rate. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to less than 1 f/s
The Delay between Iterations is configured when using DUTs that need more time to process the group leave messages in order to remove the groups from the table before the next iteration group joins are sent.
9-32

Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3 Packet Streams mode Receive port First Time Stamp
Table 9-16. Parameter Source IP List IP Multicast Group Join Delay Test - Run Parameters Description When the IGMP version parameter is set to 3, two parameters are available: V3 Message Type parameter - you can choose one of the available options: Include or Exclude. Source IP List - you can add the Source IP addresses list. When Include is selected, the source IP for the test is added to the IGMP messages. Otherwise, the messages are not modified.
9-33

Pass Criteria

Table 9-17. Parameter Pass Criteria IP Multicast Group Join Delay Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Time required by the DUT to register multicast groups. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the join delay: Average/Group: The test averages the join delay over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Group: The test selects the longest join delay experienced in each group, then applies the criteria to determine whether a trial passed or failed. Pass: The join delay was less than or equal to the time you specified. Fail: The join delay exceeded the time you specified.
Join Delay
Test Results
The following is an example of the results for the Group Join Delay test run with the values listed in Table 9-18.
Table 9-18. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Address of First Group IP Multicast Group Join Delay Test Results Sample 64 bytes 10 seconds 100 Accumulated 9 224.0.1.1
9-34

IP Multicast Group Join Delay - Accumulated - IP --> Framesize: 64 TX RX TxFrames/RxPort RxFrames #Groups GroupAddress JoinDelay(ns) ******************************************************************************************* 1.1.1 1.1.2 1488150 1117640 9 224.0.1.1 9136920 224.0.1.2 5060880 #Groups is the number of multicast 224.0.1.3 5323000 224.0.1.4 6105320 groups that this receive port joined. 224.0.1.5 2902880 224.0.1.6 4773840 Group Address: Address of each 224.0.1.7 7964800 multicast group that this receive port 224.0.1.8 5495760 224.0.1.9 3808120 1.1.1 1.1.3 1488150 263270 9 224.0.1.1 9315160 224.0.1.2 5239120 224.0.1.3 5497320 224.0.1.4 6283560 224.0.1.5 3081080 224.0.1.6 4952040 224.0.1.7 8142960 224.0.1.8 5670120 224.0.1.9 3990160 1.1.1 1.1.4 1488150 628833 9 224.0.1.1 9406840 224.0.1.2 5327920 224.0.1.3 5584200 224.0.1.4 6370440 224.0.1.5 3169880 224.0.1.6 5042760 224.0.1.7 8231800 224.0.1.8 5758920 224.0.1.9 4073200 ******************************************************************************************* %MaxRate = 100
Join Delay: Delay, in nanoseconds, between transmitting the Join request for the group and receiving traffic for the group.
9-35

Group Leave Delay Test

Overview
This test determines how long it takes a DUT to remove a client from its multicast table. The test measures the elapsed time between the time a DUT receives a group of IGMP Leave requests and the time the multicast clients stop receiving traffic for the groups they have left. The test can optionally increase or decrease the frame rate to record how different frame rates affect the delay between leaving a group and the cessation of traffic. This test requires a minimum of four ports; namely one to transmit, at least two to receive, and one to act as the timing port that allows the test to derive timing information for the validation traffic. This test uses a one-to-many mapping.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address with a step of 1 and the number of increments equal to the value configured for Total Group Addresses to find the range of groups and their addresses. For example, using the default values for both parameters (First Group Address = 224.0.1.1 and Total Group Addresses = 9), the ports try to join ten groups, with addresses 224.0.1.1 through 224.0.1.9. The test allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports.
9-36

After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. Each receive port should receive only traffic intended for the groups that they joined. If any of the receive ports receives a frame addressed to a group that it did not join, this indicates that the DUT is misrouting or leaking frames. The transmit port sends a certain amount of traffic to the multicast groups that the receive ports joined. If the receive ports receive the traffic, the test assumes that the DUT processed the Join messages successfully. After receiving the transmitted traffic, the receive ports signal that they no longer want to receive traffic for their groups by sending IGMP Leave Group messages to the DUT. Rate specifies the rate at which the test sends the Leave Group messages. The timing port records the timestamps on the Leave Group messages, and the timestamps on the last multicast message received for each group. If you specified more than one iteration, the test repeats with the same frame size but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to less than 1 f/s
If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations. The Delay between Iterations is configured when using DUTs that need more time to process the group leave messages in order to remove the groups from the table before the next iteration group joins are sent.
Supported Protocols
9-37

Supported Protocols
Features Required on Ports Transmit port Receive port First Time Stamp
Packet Streams mode
Pass Criteria

Table 9-19. Parameter Pass Criteria IP Multicast Group Leave Delay Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Time required by the DUT to de-register multicast groups. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of two methods to calculate the leave delay: Average/Port: The test averages the leave delay over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest leave delay experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The leave delay was less than or equal to the time you specified. Fail: The leave delay exceeded the time you specified.
Leave Delay
Test Results
The following is an example of the results for the Group Leave Delay test run with the values listed in Table 9-20.
9-38

Table 9-20. Frame Size: Duration: Max Rate Increment% Group Type: Total Group Addresses:
IP Multicast Group Leave Delay Test Results Sample 64 bytes 10 seconds 10 10 Accumulated 9 224.0.1.1
Address of First Group
TxFrames/RxPort lists the number of frames transmitted to the multicast groups associated with this receive port. RxFrames lists the number of frames that the DUT was able to forward from the transmit port to the receive port.
IP Multicast Group Leave Delay - Accumulated - IP --> Framesize: 64 TX RX TxFrames/RxPort RxFrames #Groups GroupAddress LeaveDelay(ns) *************************************************************************************** 1.1.1 1.1.2 297660 39707 11 224.0.1.1 2668530360 224.0.1.2 2658592760 #Groups is the number of multicast 224.0.1.3 2648664760 groups that this receive port joined. 224.0.1.4 2637992760 224.0.1.5 2628059960 224.0.1.6 2618127160 Group Address: Address of each 224.0.1.7 2607455200 multicast group that this receive port joined 224.0.1.8 2597517600 224.0.1.9 2587589600 224.0.1.10 2577656800 224.0.1.11 2566984800 1.1.1 1.1.3 297660 39707 11 224.0.1.1 2668526160 224.0.1.2 2658593360 224.0.1.3 2648660560 224.0.1.4 2637988600 224.0.1.5 2628055800 224.0.1.6 2618123000 224.0.1.7 2607451000 224.0.1.8 2597518200 224.0.1.9 2587585400 24.0.1.10 2577652600 224.0.1.11 2566980640 *************************************************************************************** %MaxRate = 10
Leave Delay: Delay, in nanoseconds, between transmitting the Leave Group request for the group and receiving the last packet traffic for the group.
9-39

Latency Test
Latency Test
This section covers the following topics: Overview on page 9-40. Test Cycle on page 9-40. Supported Protocols on page 9-42. Test Setup: Run Parameters on page 9-42. Configuring Multiple VLANs on a Port on page 9-43. Pass Criteria on page 9-43. Test Results on page 9-44.
Overview
This test measures the average, minimum, and maximum latencies of multicast frames sent to clients on multiple subnets (ports). The Latency test reveals the range of variation in the processing overhead that the DUT requires to forward multicast frames. The test allows the configuration of multiple VLANs on each transmit port and multiple VLANs on each receive port. If the transmit port is configured to send tagged VLAN traffic, it applies the VLAN ID to all traffic sent from it. If more than one VLAN is configured on a transmit port, the test distributes the multicast groups among the VLANs.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Load Rate parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. For example, using the default values for both parameters (First Group Address = 224.0.1.1 and Total Group Addresses = 20), the ports try to join twenty groups, with addresses 224.0.1.1 through 224.0.1.20. The test allocates the addresses to join according to the value that you specified for the Group Type parameter: If you set Group Type to Distributed, the test distributes the addresses among the ports.
9-40

Latency Test
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Load Rate. While the transmit port is transmitting the validation traffic: If the Tagged Frame latency measuring method is chosen, the test tags a special frame and inserts it into the stream of normal frames. When the ports receive the tagged frame, the test compares its timestamp with the current time and calculates the difference between the two-time values. The resulting difference is the latency. The test records the average, minimum, and maximum latencies for each multicast group. If the Min Max latency measuring method is chosen, the test sends normal frames. When the ports receive the frames, the test compares their timestamp with the current time and calculates the difference between the two-time values. The resulting difference is the latency. The test records the average, minimum, and maximum latencies for each multicast group.
If you check Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Rate after the test has transmitted all the traffic. If you specified more than one iteration, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. If you specified more than one trial for No. of Iterations, the test repeats the specified number of iterations. If you set the ARP and IGMP Messages Frequency parameter messages to On Iteration, the test resends the ARP or IGMP Join messages to the DUT for each new iteration. If you set the Enable 802.1q Tag option and Automatic traffic map, the VLAN parameters can also be set. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to less than 1 f/s
If you specified more than one trial for No. of Trials, the test repeats for the specified number of trials. If you set the ARP and IGMP Messages Frequency parameter messages to On Trial, the test resends the ARP or IGMP Join messages to the DUT for each new trial.
9-41

Latency Test
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3 Packet Streams mode Receive port Wide Packet Groups mode
Table 9-21. Parameter Measuring Method IP Multicast Latency Test - Run Parameters Description Choose one of the following methods to calculate the latency: Tagged Frame method special tagged frames are sent and only their latency is recorded. The algorithm description: first determine the throughput for the DUT for each of the listed frame sizes. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream should be at least 120 seconds (s) in terms of duration. An identifying tag is included in one frame after 60 s, with the type of tag being implementation-dependent. The time at which this frame is fully transmitted is recorded (timestamp A). The receiver logic in the test equipment must recognize the tag information in the frame stream and record the time at which the tagged frame was received (timestamp B). Min Max Method calculates the latency for all the sent frames. VLANs on TX Port VLANs on Rx Port The number of VLANs per each transmit port The number of VLANs per each receive port
9-42

Latency Test
Configuring Multiple VLANs on a Port
To configure more than one VLAN on a port: 1. Specify the VLAN ID of the first VLAN and the number of VLANs per port. IxAutomate assigns the VLAN ID to the first VLAN and increments the VLAN ID by one to create the subsequent VLAN IDs. For example, if you specify VLAN ID as 101 and the # VLANs as 3, then the port is configured with VLANs 101, 102, and 103. 2. Each VLAN has its own IP and Gateway addresses. The IP and Gateway addresses of the first VLAN are the ones specified in the First Port Source Address and First Port Gateway/DUT Address fields. The subsequent IP and gateway addresses are derived by incrementing one of the octets in these addresses. The Mask Width field determines which octet is to be incremented by the test. For example, if you configure the following:
VLAN ID #VLANs
101 3
First Port Source Address 198.18.7.100 First Port Gateway/DUT Mask Width 198.18.7.1 24
the resulting configuration is:
VLAN 101 102 103
Source IP Address 198.18.7.100 198.18.8.100 198.18.9.100
Gateway/DUT 198.18.7.1 198.18.8.1 198.18.9.1
Pass Criteria
Table 9-22 lists the pass criteria available for this test.
9-43

Latency Test
IP Multicast Latency Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Group: The test averages the latency over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Group: The test selects the longest latency experienced on each group, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Pass Criteria
Latency
Test Results
The following is an example of the results for the Latency test run with the values listed in Table 9-23.
Table 9-23. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Address of First Group Number of VLANs on TX port First VLAN ID IP Multicast Latency Test Results Sample 512 bytes 10 seconds 30 Distributed 10 224.0.1.1 3 1400
Note: The VLAN ID shown in the test results is the transmit ports VLAN ID.
9-44

Mesh Test
Min and Max. are the shortest and longest latencies recorded, in nanoseconds, for the multicast address.
Group Addresses are the addresses of the multicast groups that the receive port joined.
%MaxRate is the value configured for the Load Rate parameter.
%Loss is the percentage of transmitted frames that the DUT failed to forward
Avg. Latency is the average delay, in nanoseconds, between transmitting a multicast frame to the DUT and the multicast client (receive port) receiving it
Mesh Test
Overview
The Mesh test measures the DUTs throughput per port while it is receiving and forwarding frames on all ports. This test is similar to the RFC 2889 Fully Meshed test, except that this test uses multicast frames. This test requires a minimum of three ports. This test uses a many-to-many traffic mapping; each port transmits to, and receives from all the other ports.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages.
9-45

Mesh Test
Each port joins one multicast group on the DUT. The First Group Address parameter determines the address of the first group. The test increments the last octet in the First Group Address to assign the remaining addresses. For example, using the default value for First Group Address, 224.0.1.1, and four ports, the ports try to join four multicast groups with addresses 224.0.1.1 through 224.0.1.4. After the ports have sent their Join messages, each port sends validation traffic (IP frames) addressed to every multicast group in the test, except the one that it joined. For example, Table 9-24 shows the pattern of groups joined and transmitted to using the default First Group Address and four ports.
Table 9-24. Port 1 2 3 4 Distribution of Groups in Mesh Test transmits to groups 224.0.1.2 224.0.1.1 224.0.1.1 224.0.1.1 224.0.1.2 224.0.1.2 224.0.1.3 224.0.1.3 224.0.1.3 224.0.1.4 224.0.1.4 224.0.1.4
joins group 224.0.1.1 224.0.1.2 224.0.1.3 224.0.1.4
The ports transmit the traffic at the rate specified for Max Rate. If you specified more than one iteration, the test changes the frame rate based on the value for Increment, and repeats. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. If you set the ARP and IGMP Messages Frequency parameter messages to On Iteration, the test resends the ARP or IGMP Join messages to the DUT for each new iteration. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to less than 1 f/s
If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations. If you set the ARP and IGMP Messages Frequency parameter messages to On Trial, the test resends the ARP or IGMP Join messages to the DUT for each new trial.
Supported Protocols
9-46

Mesh Test
Supported Protocols
Packet Flow mode
For more information about the common run parameters, see Run Parameters on page 9-13.
Note: For the ATM cards, if the Load Rate parameter reaches a value greater than the supported one (100/total number of configured ports), some errors are printed in the Log file as a consequence of the DUT's congestion.
For information about the common settings for the IP Multicast tests, see Setting Up the Tests on page 9-9. For information about other tests in this family, see IP Multicast (RFC 3918) Test Suite on page 9-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
9-47

Mesh Test
Pass Criteria

Table 9-25. Parameter Pass Criteria IP Multicast Mesh Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of these two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Test Results
The following is an example of the results for the Mesh test with a 64-byte frame size (see Table 9-26).
Table 9-26. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Address of First Group IP Multicast Mesh Test Results Sample 64 bytes 10 seconds 100 Distributed 4 224.0.1.1
9-48

Throughput No Drop Rate Test
TxFrames lists the number of frames transmitted to this receive port. RxFrames lists the number of frames that the DUT was able to forward to the multicast groups associated with this receive port.
IP Multicast Mesh - Distributed - IP --> Framesize: 64 PortId TxFrames RxFrames FirstGroup LastGroup #Groups ******************************************************************************* 1.1.1 1488099 1487194 224.0.1.4 224.0.1.4 1 1.1.2 1488099 1487226 224.0.1.1 224.0.1.1 1 1.1.3 1488099 1071904 224.0.1.2 224.0.1.2 1 1.1.4 1488099 1487317 224.0.1.3 224.0.1.3 1 ******************************************************************************* %MaxRate = 100 TotalTxFrames = 5952009 First Group and Last #Groups is the number TotalRxFrames = 5533641 Group are the IP addresses of multicast groups that TotalLoss(%) = 7.029
of the first and last multicast groups this receive port joined
the receive port joined.
%MaxRate is the value configured for the Max Rate parameter. TotalTxFrames is the total number of frames transmitted to all ports. TotalRxFrames is the total number of frames received on all ports. Total Loss(%) is the percentage of all frames transmitted that the DUT failed to forward.

This section covers the following topics: Overview on page 9-49. Test Cycle on page 9-50. Supported Protocols on page 9-51. Run Parameters on page 9-51. Pass Criteria on page 9-54. Test Results on page 9-54.
Overview
This test determines the maximum throughput that the DUT can support while receiving and transmitting multicast traffic. It allows you to calculate the maximum DUT Throughput using either a binary or a linear search, and to collect Latency and Data Integrity statistics. The test is patterned after the ATSS Throughput test. However, this one uses multicast traffic. A one-to-many traffic mapping is used, with a minimum of two ports required.
9-49

If OSPF or ISIS is chosen as IGP protocol routing, the transmit port first establishes an IGP routing protocol session and a PIM session with the DUT. IGMP joins are then established for each group, on each receive port. If None is chosen as IGP protocol routing, the transmit port does not emulate routers and does not export routes to virtual sources. Static routes should be added on the DUT. The source addresses are the IP addresses configured on the Tx ports in Data Frame. To run a test, you must create static routes.
Test Cycle
The test begins by configuring the protocols for the source and destination ports: For the source ports, you can select: OSPF or ISIS protocol and the Interface Network Type and the Level or Area ID for each protocol. The source port simulates the PIM routers establishing an OSPF or ISIS session. None option in order to run the test without using any routing protocol. For the destination ports, you can set the multicast protocol (IGMP / MLD / PIM-SM / PIM-SSM) depending on the protocol that you choose for Data Frame (IPv4, IPv6).
If ARP is enabled, the ports send ARP frames at the configured rate so that the DUT can learn the Ixia ports addresses. The receive ports send Join requests to the DUT. The setting of the IGMP Version determines the format of the Join messages. The First Group Address and Total Group Address parameters determine the groups that the receive ports try to join. The First Group Address is the address of the first group and Total Group Address is the number of group addresses to be assigned to each port. The test iterates between First Group Address and Total Group Address to find the range of the groups and their addresses. The test allocates the addresses to join according to the value that you specified for Group Type: Distributed means that the test divides the test addresses among the ports Accumulated means that the test duplicates the same addresses on every receive port.
After the multicast receive ports have sent their Join messages, the multicast transmit ports begin sending validation traffic (IP multicast frames), based on the values of Duration and Load Rate, addressed to each group that the multicast receive ports joined. The Search Type parameter determines how the maximum throughput is calculated: Binary Search algorithm description if a port pair drops frames, it searches downwards for a lower rate. If a port pair does not drop frames, it searches upwards for a higher rate. To choose a lower rate, the test divides the previous rate in half, and uses the result as the new rate. To find a higher rate, it divides the previous rate in half and adds it to the previous rate. The test searches
9-50

among higher and lower rates until it finds the rate at which no frames are lost. The binary search process continues until the test finds the rate, within the specified tolerance, at which no frames are lost. If the test performs the first iteration and no frames are received, then a second iteration is performed; after that, if no frames are received, the test stops; otherwise, the binary search algorithm continues. If Linear Search is used, the initial iteration value and the iteration increment value are configurable.
After all the traffic has been sent, the test records the Latency and Data Integrity statistics and calculates the throughput. If more than one trial was requested, the test repeats for the specified number of iterations.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3, PIM, OSPF or ISIS Packet Streams mode Receive port Capture mode
Run Parameters
Table 9-27. Field Binary Search Staggered Transmit Throughput No Drop Rate - Run Parameters Usage Determines the test throughput using the binary search algorithm. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you use staggered transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously. Other Parameters
9-51

Table 9-27. Field
Throughput No Drop Rate - Run Parameters (Continued) Usage You can set the following parameters: IGP Protocol the inter-gateway protocol used on the source ports. You can select OSPF, ISIS, or None. Receiver Multicast Protocol the protocol for the destination ports. You can select IGMP, MLD, PIMSM, or PIM-SSM. Interface Network Type Select Broadcast or Point to Point. This parameter is available if you set OSPF or ISIS as IGP protocol. Area ID or ISIS Level, depending on the IGP protocol that you selected This parameter is available if you set OSPF or ISIS as IGP protocol. DUT Delay it represents the time allowed for DUT processing before traffic transmit.
Protocols Parameters
Receiver Parameters
In addition to the common parameters, you can set the following parameters: Number of Emulated Receivers Port represents the number of the receiver ports for each destination port. Group Address Count Per Emulated Receiver represents the number of receivers from a group. Group Type determines how addresses are allocated among ports: Accumulated or Distributed.
Source Parameters
In addition to the common parameters, you can set the following parameters: Number of Emulated PIM Routers Per Port If the IGP protocol is set to None, it represents the number of source addresses used in the validation traffic. Emulated PIM Routers are not created/ started on Ixia ports. Otherwise, emulated PIM Routers are created/started on Ixia ports. Source Address Count per emulated PIM Router If the IGP protocol is set to None, it represents the number of source addresses. The source addresses start with the address configured on the Tx port, which is incremented according to the number of sources. Number of Sources = Number of Emulated PIM Routers Per Port * Source Address Count Per Emulated PIM Router Rendezvous Point Address this represents the IP address of the PIM-SM Router necessary to send traffic. This parameter is available if you set OSPF or ISIS as IGP protocol.
For more information about the common run parameters, see Run Parameters on page 9-13.
9-52

For information about the common settings for the IP Multicast tests, see Setting Up the Tests on page 9-9. For information about other tests in this family, see IP Multicast (RFC 3918) Test Suite on page 9-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
9-53

Pass Criteria
The pass criteria for this test are listed in Table 9-28.
Table 9-28. Parameter Pass Criteria Throughput No Drop Rate - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was lower than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
Test Results
For linear searches, the available results for each iteration are: TxTput in f/s and % AvgLatency MinLatency MaxLatency Data Errors
9-54

Mixed Class Throughput Test
For each binary search iteration, the following results are available in pairs (Tx and Rx): Offered Load Rate in Kb/s, %, or f/s MaxTxRate (%) AvgTxRunRate AvgRxRunRate
Uniquely for the final iteration, the results are the same as for linear search.

Overview
This test measures DUT throughput when receiving and forwarding mixtures of unicast and multicast frames. This test stresses the DUT by requiring it to operate under the conditions found on a real internetwork, which consists of a mixture of unicast and multicast packets. This test uses a one-to-many traffic mapping. You must allocate at least two ports, one to transmit and one to receive.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. The Mixed Class Parameters determines how the test balances the percentages of unicast and multicast frames within the transmit traffic. The Unicast and Multicast sum percentages always have to be 100. If you set Unicast to 10, Multicast is automatically set to 90. The test applies the values that you select for the Unicast and Multicast parameters to the value for Max Rate to determine the transmit speed. For example, if you set Unicast to 10, Multicast to 90, and Max Rate to 50, the test transmits unicast traffic at 5 percent of the maximum port speed (10% of 50 = 5) and multicast traffic at 45 percent of the port speed (90% of 50 = 45). If you check Enable ARP, the ports send ARP frames at the rate specified for Rate so that the DUT can learn the Ixia ports addresses.
9-55

The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. The test allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports. If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
After the receive ports have sent their Join messages, the transmit ports begin sending validation traffic (IP multicast frames) addressed to each group that the receive ports joined. All the transmit ports transmit at the rate specified for Max Rate. After the test has transmitted all the unicast and multicast traffic, the test records the results and calculates the throughput for the iteration. If you check Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Rate. If you specified more than one for No. of Iterations, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Max Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. To reduce the transmit rate, specify a negative value for Increment. If you specify a combination of No. of Iterations and Increment values that causes the transmit rate to drop to 1 f/s or less, the test stops for that frame size. If you set the ARP and IGMP Messages Frequency parameter messages to On Iteration, the test re-sends the ARP or IGMP Join messages to the DUT. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to 1 f/s or less
If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations. If you set the ARP and IGMP Messages Frequency parameter messages to On Trial, the test resends the ARP or IGMP Join messages to the DUT.
9-56

Supported Protocols

Supported Protocols Features Required on Ports Transmit port MAC; IP; IPv6; VLANs; IGMP v1, 2, and 3; MLD v1 and 2 Packet Streams mode Receive port Capture mode
Table 9-29. Parameter Test Parameters Increment The percentage increase (positive value) or decrease (negative value) in the transmission rate for each iteration. IP Multicast Mixed Class Throughput Test - Run Parameters Description
Mixed Class Parameters Unicast / Multicast Percentages of unicast and multicast frames within the traffic stream. The sum of the mix traffic is always 100. Max Rate determines the speed at which the test transmits and the test applies the values for Unicast and Multicast to the Max Rate value. Enable Layer 2 Select this option if the DUT is a Layer 2 device. Then specify the values for Port Mac Address, Increment Value for Port Mac Address, First Multicast Dest Address and Increment value for Multicast Dest Address.
9-57

Pass Criteria
Table 9-30. Parameter Pass Criteria IP Multicast Mixed Class Throughput Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Group: The test averages the frame loss over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Group: The test selects the largest amount of frame loss experienced in each group, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Test Results
The following is an example of the results for the Mixed Class Throughput run with the values listed in Table 9-31.
Table 9-31. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Address of First Group IP Multicast Mixed Class Throughput Test Results Sample 64 bytes (multicast and unicast) 10 seconds 60 Distributed 9 224.0.1.1
For details, refer to the following topics: Results for Multicast Frames on page 9-59. Results for Unicast Frames on page 9-60.
9-58

Results for Multicast Frames

TxFrames/RxPort lists the number of Multicast transmit / receive port pair. multicast frames transmitted to the multicast #Groups is the number of multicast groups that this receive port joined. groups associated with this receive port. TX: Transmit port RX: Receive port RxFrames lists the number of multicast frames that the DUT was able to forward from the transmit port to the receive port.
IP Multicast Mixed Class - Distributed - IP --> Framesize: 64/64 Multicast Ports: TX RX TxFrames/RxPortRxFrames %Loss RxRate(fps) RxRate(%) FirstGroup LastGroup #Groups ********************************************************************************************************** 1.1.1 1.1.3 99200 99200 0.000 9920 6.67 224.0.1.1 224.0.1.5 5 1.1.1 1.1.4 79360 79360 0.000 7936 5.33 224.0.1.6 224.0.1.9 4 ********************************************************************************************************** %MaxMulticastRate = 60 TotalMcastTxFrames = 178560 Loss(%) is the percentage of First Group and Last Group are the IP TotalMcastRxFrames = 178560 multicast frames that the DUT addresses of the first and last multicast %Loss = 0.000
failed to forward from the transmit port to the receive port.
groups this receive port joined
%MaxMulticastRate is the rate at which the test trasmitted the multicast traffic. TotalTxFrames is the total number of multicast frames transmitted to all ports. TotalRxFrames is the total number of multicast frames received on all ports. %Loss is the percentage of all multicast frames transmitted that the DUT failed to forward.
RxRate(fps) and RxRate(%) are the rates at which the receive port received multicast traffic from the DUT. For RxRate(%), the rate is expressed as a percentage of the maximum port speed.
9-59

Scale Group Test
Results for Unicast Frames

Unicast transmit / receive port pair. TX: Transmit port RX: Receive port TxFrames lists the number of unicast frames transmitted to the receive port. Loss(%) is the percentage of unicast frames that the DUT failed to forward from the transmit port to the receive port.
Unicast Ports: TX RX TxFrames RxFrames %Loss RxRate(fps) RxRate(%) ******************************************************************************** 1.1.2 1.1.1 714290 714290 0.000 71429 48.00 1.1.3 1.1.4 714290 714290 0.000 71429 48.00 ******************************************************************************** %MaxUnicastRate = 60 RxRate(fps) and RxRate(%) ar TotalUcastTxFrames = 1428580 the rates at which the receive TotalUcastRxFrames = 1428580 RxFrames lists the number of unicast port received multicast traffic %Loss = 0.000 frames that the DUT was able to forward
from the transmit port to the receive port.
%MaxUnicastRate is the rate at which the test trasmitted the unicast traffic. TotalTxFrames is the total number of unicast frames transmitted to all ports. TotalRxFrames is the total number of unicast frames received on all ports. %Loss is the percentage of all unicast frames transmitted that the DUT failed to forward.
from the DUT. For RxRate(%), the rate is expressed as a percentage of the maximum por speed.
Scale Group Test

Overview
This test determines a DUTs multicast throughput by transmitting a fixed quantity of traffic to each multicast group and increasing or decreasing the number of multicast groups. This test can reveal how rapidly the DUTs multicast throughput increases or decreases when the number of groups it must forward traffic to changes. Because each receive port may simulate different numbers of multicast groups during the test, the total numbers of frames received on each port may vary from one iteration to another as the number of multicast groups changes. If you divide the number of frames received on a port by the number of groups on the port, the per-group number of frames received is constant for each iteration as long as the DUT does not lose any frames.
9-60

Scale Group Test
This test requires a minimum of three ports; one to transmit and two to receive, and uses a one-to-many traffic mapping.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Max Rate parameters. If you check Enable ARP, the ports send ARP frames at the rate specified for Rate so the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. The tests allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports. If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Max Rate. After the test has transmitted all the traffic, it sends Leave Group messages at the rate specified for Rate to unsubscribe from the groups that it joined. For the next iteration, the test changes the number of groups that the receive ports join. The Increment Addr parameter determines the number of additional groups. To calculate the new number of groups, the test adds the value of Increment Addr to the number of groups in the previous iteration. As with the previous iteration, the test allocates the groups to the ports according to the Group Type parameter. The receive ports send new IGMP Join requests to the DUT to join their new groups. The Enable Leave Group parameter determines how many Join messages the ports send: If the ports did not send Leave Group messages at the end of the previous iteration, (Enable Leave Group was not checked), the receive ports send only Join messages to the additional new groups they are joining in this iteration. If the ports did send Leave Group messages at the end of the previous iteration, the receive ports send Join messages to all the groups they are joining for this iteration, including the ones they joined in the previous iteration.
9-61

Scale Group Test
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. After it has sent all the traffic, the test records the throughput. The test continues until it has run for the specified number of iterations. It then calculates the results for all the iterations. If you specified more than one trial for No. of Trials, the test repeats the specified number of iterations.
Supported Protocols

Table 9-32. Parameter Increment Addr. IP Multicast Scale Group Test - Run Parameters Description The number of addresses to add or subtract (specify a negative number) to the Total Group Addresses for each iteration.
Pass Criteria
9-62

Scale Group Test
IP Multicast Scale Group Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of frames transmitted that were lost by the DUT. You can select either of these two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Pass Criteria
% Frame Loss
Test Results
The following is an example of the results for the Scale Group test run with the values listed in Table 9-34.
Table 9-34. Frame Size: Duration: Max Rate Group Type: Total Group Addresses: Address of First Group IP Multicast Scale Group Test Results Sample 64 bytes (multicast and unicast) 10 seconds 100 Distributed 100 224.0.1.1
9-63

Tunneling Throughput Test
TxFrames/RxPort lists the number of frames transmitted to this receive port. RxFrames lists the number of frames that the DUT was able to forward from the transmit port to the multicast groups associated with this receive port.
IP Multicast Scale Group - Distributed - IP --> Framesize: 64 TX RX TxFrames/RxPortRxFrames Loss(%) FirstGroup LastGroup #Groups *********************************************************************************************** 1.1.1 1.1.2 505920 505042 0.174 224.0.1.1 224.0.1.34 34 1.1.1 1.1.3 491040 488999 0.416 224.0.1.35 224.0.1.67 33 1.1.1 1.1.4 491040 487820 0.656 224.0.1.68 224.0.1.100 33 *********************************************************************************************** %MaxRate = 100 TotalTxFrames = 1488000 Loss(%) is the First Group and Last #Groups is the TotalRxFrames = 1481861 percentage of frames Group are the IP addresses number of multicast TotalLoss(%) = 0.413 that the DUT failed to of the first and last multicast groups that this receive
forward from the transmit port to the receive port. %MaxRate is the value configured for the Max Rate parameter. TotalTxFrames is the total number of frames transmitted to all ports. TotalRxFrames is the total number of frames received on all ports. TotalLeaked is the total number of all frames the DUT forwarded to the wrong multicast groups. Total Loss(%) is the percentage of all frames transmitted that the DUT failed to forward.
groups this receive port joined.
port joined.

This section covers the following topics: Overview on page 9-64. Test Cycle on page 9-65. Configuring IP Addresses for the Tunnels on page 9-68. Supported Protocols on page 9-68. Run Parameters on page 9-69. Pass Criteria on page 9-70. Test Configuration Sample on page 9-70. Test Results on page 9-73.
Overview
This test determines the multicast throughput when a DUT or a set of DUT interfaces act as tunnel endpoints. Throughput represents the highest rate at which the DUT receives and forwards frames with loss lower than or equal to the specified value for loss tolerance. A binary search algorithm is used to determine the throughput.
9-64

In this test, encapsulation or tunneling refers to a packet that contains an unsupported protocol feature in a format that is supported by the DUT. The GRE format is used as encapsulation mode for configuring the Tx and Rx ports. A one-to-many traffic mapping is used, with a minimum of two ports required. This test supports only one map, which means that only one transmit port must be set. Three types of tunneling throughput measurements designed for different setup configurations are available for this test: Encapsulation throughput it calculates the maximum rate at which frames offered to one ingress interface of a DUT are encapsulated and correctly forwarded to one or more egress interfaces of the DUT with loss lower than or equal to the specified value for loss tolerance. Decapsulation throughput it calculates the maximum rate at which encapsulated frames offered to one ingress interface of a DUT are decapsulated and correctly forwarded by the DUT to one or more egress interfaces with loss lower than or equal to the specified value for loss tolerance. Re-encapsulation throughput it calculates the maximum rate at which frames of one encapsulated format offered to one ingress interface of a DUT are converted to another encapsulated format and correctly forwarded by the DUT to one or more egress interfaces with loss lower than or equal to the specified value for loss tolerance.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Load Rate parameters. If ARP is enabled, the ports send ARP frames at the configured rate, so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. The DUT receives the Join requests from: The tunnel endpoints, if the encapsulation or re-encapsulation throughput measurement method is set; The receive ports, if the decapsulation or re-encapsulation throughput measurement method is set.
The setting of the IGMP version/MLD version determines the format of the Join messages. The First Group Address and Group Addresses Per Rx Tunnel parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group and Group Addresses Per Rx Tunnel is the number of group addresses to be assigned: To each Rx tunnel, if the encapsulation or re-encapsulation measuring throughput method is set; To each Rx port, if the decapsulation measuring throughput method is set.
9-65

The test iterates between First Group Address and Group Addresses Per Rx Tunnel to find the range of the groups and their addresses. The test allocates the addresses to join according to the value that you specified for Group Type: Distributed means that the test divides the test addresses among the tunnels on the same receive port Accumulated means that the test duplicates the same addresses on every tunnel.
9-66

For example if you have the following settings:

No. of Tunnels per Rx Port First Group Address: Group Addresses per Rx Tunnel: 2 227.0.0.1 6
If Group Type is set to Distributed: Tunnel 1 joins the groups: 227.0.0.1; 227.0.0.2; 227.0.0.3; Tunnel 2 joins the groups: 227.0.0.4; 227.0.0.5; 227.0.0.6
If Group Type is set to Accumulated: Tunnel 1 joins the groups: 227.0.0.1; 227.0.0.2; 227.0.0.3; 27.0.0.4; 227.0.0.5; 227.0.0.6; Tunnel 2 joins the groups: 227.0.0.1; 227.0.0.2; 227.0.0.3; 27.0.0.4; 227.0.0.5; 227.0.0.6;
According to the tunneling throughput measurement method that you choose, the test continues for different test setup configurations: Encapsulation throughput method One or more tunnels are created between each egress interface of the DUT and a destination test port. The non-encapsulated multicast traffic is offered by the source test port, then it is encapsulated by the DUT and forwarded to the destination port(s). NOTE: When offering large frames sizes, the encapsulation process may require the DUT to fragment the IP datagrams before they are forwarded on the egress interface. You must limit the offered frame size so that no fragmentation is required by the DUT, as it is not supported in this test. Decapsulation throughput method One or more tunnels are created between the source test port and the DUT. The encapsulated multicast traffic is offered by the source test port, then decapsulated by the DUT and forwarded to the destination test port(s). Re-encapsulation throughput method The source test port offers encapsulated traffic of one type to the DUT, which has been configured to re-encapsulate the offered frames using the same encapsulation format. The DUT then forwards the re-encapsulated frames to the destination test port(s).
The binary search algorithm is used to determine the maximum throughput for all the above test configurations. If you specified more than one trial, the test restarts, using the same frame sizes. Each time the test repeats, it calculates the DUTs throughput. After all the trials for that frame sizes complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all trials and frame sizes complete. It then gathers statistics on the
9-67

number of transmitted and lost packets and the forwarding rate. After gathering statistics, it prints the results.
Configuring IP Addresses for the Tunnels
Using the GRE tunnels on ingress and/or egress interfaces, depending on the measuring method, a set of two interfaces is required, both on the DUT and on Ixia ports: The first interface on both the DUT and Ixia ports uses the IP addresses which define the network level connection between the DUT and the Ixia ports. The second interface on each port is used as GRE tunnel endpoint on both DUT and Ixia ports. The tunnel IP Addresses are used to this end. Table 9-35 describes the parameters that can be set (Frame Data widget).
Tunneling Throughput - Frame Data Tunnel Parameters Description The first IP address set on the first Ixia tunnel endpoint. This field determines which octet the test increments in the tunnel network. The IP address for the first tunnel destination. The octet that increments the tunnel destination address. If you enable it, the IP destination address is incremented. If you do not enable it, the IP destination address is not incremented.
First Ixia Tunnel IP/ IPv6 Address Tunnel Network Mask Width First Tunnel Destination Address Tunnel Destination Increment Mask Increment Tunnel Destination Address
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3, MLDv1,2 Packet Streams mode Receive port Wide Packet Group mode
9-68

Run Parameters
Table 9-36. Field No. of Tunnels per Tx port No. of Tunnels per Rx port Tunneling Throughput Run Parameters Usage The number of tunnels per each transmit port The number of tunnels per each receive port
Tunneling Throughput Measurement Encapsulation Throughput This method calculates the maximum rate at which frames offered to one ingress interface of a DUT are encapsulated and correctly forwarded to one or more egress interfaces of the DUT with loss lower than or equal to the specified value for loss tolerance. This method calculates the maximum rate at which encapsulated frames offered to one ingress interface of a DUT are decapsulated and correctly forwarded by the DUT to one or more egress interfaces with loss lower than or equal to the specified value for loss tolerance. This method calculates the maximum rate at which frames of one encapsulated format offered to one ingress interface of a DUT are converted to another encapsulated format and correctly forwarded by the DUT to one or more egress interfaces with loss lower than or equal to the specified value for loss tolerance.
Decapsulation Throughput
Re-encapsulation Throughput
9-69

Pass Criteria
Table 9-37. Parameter Pass Criteria Tunneling Throughput Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Group: The test averages the latency over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Group: The test selects the longest latency experienced on each group, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was lower than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
Test Configuration Sample
The test configuration sample helps you understand how the Ixia ports and the DUT must be set in order to be able to run a test.
9-70

The common configurations are presented in Table 9-38.

Table 9-38. Tunneling Throughput - Test Settings Sample
Traffic Setup Parameters Mode: First Port Source Address First Port Gateway/DUT Mask Width First Ixia Tunnel IP Address Tunnel Network Mask Width First Tunnel Destination Address: Tunnel Destination Increment Mask Increment Tunnel Destination Address Test Setup Parameters No. of Tunnels Per Tx Port No. of Tunnels Per Rx Port 2 2 Automatic 198.1.1.10 198.1.1.1 24 192.168.1.1 24 21.1.1.1 24 Enabled
Figure 9-5 shows the traffic workflow (green arrows), also pointing out the important elements (ports, interfaces, tunnels) for this test.
Ixia Ports
Port 1 T1 T2
Interface 1
DUT
Network
Port 2 T3 T4
Interface 2
Network
Port 3 T5 T6
Interface 3
Network
Figure 9-5.
IP Multicast Tunneling Throughput
Table 9-39 on page 9-72 lists the Ixia ports settings for the three tunneling throughput measuring methods according to: the test settings sample (Table 9-38 on page 9-71)
9-71

the test configuration in Figure 9-5 on page 9-71.

NOTE: 1. For Encapsulation, the transmit port has no tunnels and no simulated network; the IP addresses are reserved, but the tunnels are not used. 2. For Decapsulation, the receive ports have no tunnels and no simulated networks.
Table 9-39. Ixia Ports Port 1
Tunneling Throughput - Ixia Ports Test Configuration Sample Encapsulation IP address: 198.1.1.10 Gateway: 198.1.1.1 /24 Decapsulation IP address: 198.1.1.10 Gateway: 198.1.1.1 /24 IP addr:192.168.1.1 / 24 Source IP addr: 198.1.1.10 Destination IP addr: 21.1.1.1 IP addr:192.168.2.1 / 24 Source IP addr: 198.1.1.11 Destination IP addr: 21.1.1.1 IP address: 198.1.2.10 Gateway: 198.1.2.1 / 24 Not needed Re-encapsulation IP address: 198.1.1.10 Gateway: 198.1.1.1 / 24 IP addr:192.168.1.1 / 24 Source IP addr: 198.1.1.10 Destination IP addr: 21.1.1.1 IP addr:192.168.2.1 / 24 Source IP addr: 198.1.1.11 Destination IP addr: 21.1.1.1 IP address: 198.1.2.10 Gateway: 198.1.2.1 / 24 IP addr:192.168.3.1 / 24 Source IP addr: 198.1.2.10 Destination IP addr: 21.1.2.1 IP addr:192.168.4.1 / 24 Source IP addr: 198.1.2.11 Destination IP addr: 21.1.2.1 IP address: 198.1.3.10 Gateway: 198.1.3.1 / 24 IP addr:192.168.5.1 / 24 Source IP addr: 198.1.3.10 Destination IP addr: 21.1.3.1 IP addr:192.168.6.1 / 24 Source IP addr: 198.1.3.11 Destination IP addr: 21.1.3.1
Tunnel 1 (T1)
Not needed
Tunnel 2 (T2)
Not needed
Port 2
IP address: 198.1.2.10 Gateway: 198.1.2.1 / 24
Tunnel 3 (T3)
IP addr:192.168.3.1 / 24 Source IP addr: 198.1.2.10 Destination IP addr: 21.1.2.1 IP addr:192.168.4.1 / 24 Source IP addr: 198.1.2.11 Destination IP addr: 21.1.2.1 IP address: 198.1.3.10 Gateway: 198.1.3.1 / 24
Tunnel 4 (T4)
Not needed
Port 3
IP address: 198.1.3.10 Gateway: 198.1.3.1 / 24 Not needed
Tunnel 5 (T5)
IP addr:192.168.5.1 / 24 Source IP addr: 198.1.3.10 Destination IP addr: 21.1.3.1 IP addr:192.168.6.1 / 24 Source IP addr: 198.1.3.11 Destination IP addr: 21.1.3.1
Tunnel 6 (T6)
Not needed
Table 9-40 on page 9-73 lists the DUT interfaces settings for the three tunneling throughput measuring methods according to: the test settings sample (Table 9-38 on page 9-71) and the test configuration in Figure 9-5 on page 9-71.
9-72

Table 9-40. DUT Interface 1
Tunneling Throughput - DUT Test Configuration Sample Encapsulation IP address: 21.1.1.1 Gateway: 21.1.1.1 / 24 Decapsulation IP address: 21.1.1.1 Gateway: 21.1.1.1 / 24 IP addr:192.168.1.2 / 24 Source IP addr: 21.1.1.1 Dest IP addr: 198.1.1.10 IP addr:192.168.2.2 / 24 Source IP addr: 21.1.1.1 Dest IP addr: 198.1.1.11 IP address: 21.1.2.1 Gateway: 21.1.2.1 / 24 Not needed Re-encapsulation IP address: 21.1.1.1 Gateway: 21.1.1.1 / 24 IP addr:192.168.1.2 / 24 Source IP addr: 21.1.1.1 Dest IP addr: 198.1.1.10 IP addr:192.168.2.2 / 24 Source IP addr: 21.1.1.1 Dest IP addr: 198.1.1.11 IP address: 21.1.2.1 Gateway: 21.1.2.1 / 24 IP addr:192.168.3.2 / 24 Source IP addr: 21.1.2.1 Dest IP addr: 198.1.2.10 IP addr:192.168.4.2 / 24 Source IP addr: 21.1.2.1 Dest IP addr: 198.1.2.11 IP address: 21.1.3.1 Gateway: 21.1.3.1 / 24 IP addr:192.168.5.2 / 24 Source IP addr: 21.1.3.1 Dest IP addr: 198.1.3.10 IP addr:192.168.6.2/ 24 Source IP addr: 21.1.3.1 Dest IP addr: 198.1.3.11
Tunnel 1 (T1)
Not needed
Tunnel 2 (T2)
Not needed
Interface 2
IP address: 21.1.2.1 Gateway: 21.1.2.1 / 24
Tunnel 3 (T3)
IP addr:192.168.3.2 / 24 Source IP addr: 21.1.2.1 Dest IP addr: 198.1.2.10 IP addr:192.168.4.2 / 24 Source IP addr: 21.1.2.1 Dest IP addr: 198.1.2.11 IP address: 21.1.3.1 Gateway: 21.1.3.1 / 24
Tunnel 4 (T4)
Not needed
Interface 3
IP address: 21.1.3.1 Gateway: 21.1.3.1 / 24 Not needed
Tunnel 5 (T5)
IP addr:192.168.5.2 / 24 Source IP addr: 21.1.3.1 Dest IP addr: 198.1.3.10 IP addr:192.168.6.2/ 24 Source IP addr: 21.1.3.1 Dest IP addr: 198.1.3.11
Tunnel 6 (T6)
Not needed
Test Results
The common available results for each iteration for the three tunneling throughput measuring methods are: Tx and Rx ports Originating Frame Size Hosts/Rx Port Groups Joined Offered Frames Tx Frames/Rx Port Rx Frames Frame Loss (%) Forwarding Rate (%Tx Line)
The additional test result available for the Encapsulation throughput measuring method is:
9-73

Burdened Latency Test
Encapsulated Frame Size
The additional test result available for the Decapsulation throughput measuring method is: Decapsulated Frame Size
The additional test result available for the Re-encapsulation throughput measuring method is: Re-encapsulated Frame Size

Overview
This interaction test measures the DUTs ability to forward multicast traffic with acceptable latency while forwarding meshed traffic as an interacting factor. The objective of this test is to provide a set of multicast latency measurements from a single multicast ingress interface of a DUT through multiple egress multicast interfaces of the same DUT while forwarding meshed unicast traffic. This test differs from the Latency Test on page 9-40 in that it forces the DUT to perform extra processing of packets while multicast traffic is being forwarded for latency measurements. This test uses two maps: a one-to-many traffic map for multicast traffic as in the other tests (it is a manual map) and a many-to-many traffic map for the unicast traffic as burdening traffic (it has to be fully meshed, so this is an automatic map).
The traffic maps must be totally independentthe ports used in the first map must differ from the ports used in the second map. At least five ports are required to run a test: three ports for multicast traffic and two ports for burdening (unicast) traffic.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Load Rate (for multicast traffic) parameters.
9-74

If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUT addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Load Rate. The value for IGMP Version determines the format of the Join messages. The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. For example, by using the default values for both parameters (First Group Address= 224.0.1.1 and Total Group Addresses = 20), the ports try to join twenty groups, with addresses 224.0.1.1 through 224.0.1.20. The test allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports. If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The test run contain two stages: 1. The test performs a baseline measurement of multicast latency; the latency is determined in the same way as in the Latency Test on page 9-40, when using the Tagged Frame latency measuring method. A baseline set of results is obtained with the burdening ports not enabled to send unicast traffic to the DUT. 2. The burdening ports are enabled to send meshed unicast traffic at the value specified for Load Rate Burden Ports. After the burdening traffic is started, the multicast latency test runs again and another set of results is obtained. The multicast traffic is sent at the same rate used in the baseline measurement. If you check Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Load Rate after the test has transmitted all the multicast traffic. If you specified more than one iteration, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Load Rate. For example, if you begin the test with Load Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third.
9-75

If you specified more than one trial for No. of Iterations, the test repeats the specified number of iterations. If you set the ARP and IGMP Messages Frequency parameter to On Iteration, the test resends the ARP or IGMP Join messages to the DUT for each new iteration. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to less than 1 f/s
If you specified more than one trial for No. of Trials, the test repeats for the specified number of trials. If you set the ARP and IGMP Messages Frequency parameter to On Trial, the test resends the ARP or IGMP Join messages to the DUT for each new trial.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3, MLDv1,2 Packet Streams mode Receive port Wide Packet Groups mode
9-76

Pass Criteria
Table 9-41. Parameter Pass Criteria IP Multicast Burdened Latency Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Group: The test averages the latency over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Group: The test selects the longest latency experienced on each group, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Latency
Test Results
The test results for each iteration are: Tx and Rx ports Tx Frames Rx Frames Frame Loss (%) Groups Joined Average Latency it has different values when the test runs with burdened traffic enabled and when the test runs with burdened traffic disabled; Frames Lost Burden Rate (offered load for the burden ports) Number of Burden Ports
9-77

Burdened Group Join Delay Test

Overview
This interaction test determines how long it takes a DUT to register multicast clients to a new group or to a group that already exists in the DUTs forwarding table, while forwarding meshed traffic as an interacting factor. The test measures the elapsed time between the time a DUT receives a group of IGMP Join requests and the time the multicast clients begin receiving traffic for the groups they have joined. This test differs from the Group Join Delay Test on page 9-31 in that it forces the DUT to perform extra processing of packets while multicast traffic is being transmitted to determine the group join delay. This test uses two maps: a one-to-many traffic map for multicast traffic as in the other tests (it is a manual map) and a many-to-many traffic map for the unicast traffic as burdening traffic (it has to be fully meshed, so this is an automatic map).
The traffic maps must be totally independent: the ports used in the first map must differ from the ports used in the second map. At least six ports are required to run a test: three ports for multicast traffic, two ports for burdening (unicast) traffic and one to act as the timing port that allows the test to derive timing information for the validation traffic.
Test Cycle
The test begins by calculating the number of frames to send as validation traffic based on the values for the Duration and Load Rate (for multicast traffic) parameters. If you check Enable ARP, the ports send ARP frames so that the DUT can learn the Ixia ports addresses. The receive ports send IGMP Join requests to the DUT at the rate specified for Load Rate. The value for IGMP Version determines the format of the Join messages.
9-78

The First Group Address and Total Group Addresses parameters determine the groups that the receive ports try to join. First Group Address is the address of the first group. Total Group Addresses defines the width of the address range. The test increments First Group Address by Total Group Addresses to find the range of groups and their addresses. For example, by using the default values for both parameters (First Group Address= 224.0.1.1 and Total Group Addresses = 9), the ports try to join ten groups, with addresses 224.0.1.1 through 224.0.1.9. The test allocates the addresses to join according to the value that you specified for Group Type: If you set Group Type to Distributed, the test divides the addresses among the ports. If you set Group Type to Accumulated, the test duplicates the same addresses on every receive port.
For Group Type set to Accumulated, you can choose the join delay calculation method: Join Existing Group it calculates the delay to join an existing group for which the DUT already forwards traffic. Join New Group it calculates the delay to join a group that does not exist in the DUTs forwarding table.
After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames) addressed to each group. The port transmits the traffic at the rate specified for Load Rate (for multicast parameters). Each receive port should receive only traffic intended for the groups they joined. If any of the receive ports receives a frame addressed to a group that it did not join, that indicates that the DUT is misrouting or leaking frames. The tests run includes two stages: 1. The test performs a baseline measurement of multicast group join delay; the join delay time is determined in the same way as in the Group Join Delay Test on page 9-31. A baseline set of results is obtained with the burdening ports not enabled to send unicast traffic to the DUT. 2. The burdening ports are enabled to send meshed unicast traffic at the value specified for Load Rate Burden Ports. After the burdening traffic is started, the multicast group join delay test runs again and another set of results is obtained. The multicast traffic is sent at the same rate used in the baseline measurement. If you check Enable Leave Group, the receive ports send Leave Group messages to the DUT at the rate specified for Load Rate after the test has transmitted all the multicast traffic.
9-79

If you specified more than one iteration, the test repeats with the same frame size, but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Load Rate. If you specified more than one iteration, the test changes the frame rate based on the value for Increment, and repeats. If you specified more than one iteration, the test repeats with the same frame size but with a new transmit rate. The test calculates the new rate by adding the value of Increment to the previous value of Max Rate. For example, if you begin the test with Load Rate set to 50, Increment to 10, and Iterations to 3, the test transmits the validation traffic at 50% of the maximum port speed for the first iteration, 60% for the second, and 70% for the third. At the end of each iteration, the receive ports send Leave Group messages to the DUT at the rate specified for Load Rate. The test continues for the current frame size until one of the following occurs: it has run for the specified number of iterations the transmit rate decreases to less than 1 f/s
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IGMPv1,2,3, MLDv1,2 Packet Streams mode Receive port First Time Stamp
9-80

Pass Criteria

Table 9-42. Parameter Pass Criteria IP Multicast Burdened Group Join Delay Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Time required by the DUT to register multicast groups. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the join delay: Average/Group: The test averages the join delay over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Group: The test selects the longest join delay experienced on each group, then applies the criteria to determine whether a trial passed or failed. Pass: The join delay was less than or equal to the time you specified. Fail: The join delay exceeded the time you specified.
Join Delay
Test Results
The test results for each iteration are: Tx and Rx ports Tx Frames Rx Frames Groups Joined Group Join Delay (minimum, maximum and the average values) it has different values when the test runs with burdened traffic enabled and when the test runs with burdened traffic disabled; Burden Rate (offered load for the burden ports) Number of Burden Ports
9-81

9-82
10
Chapter 10:
IPv6 Tunneling Test Suite
The sheer size and breadth of the Internet ensured that IPv6 would never be deployed and brought up simultaneously throughout the Internet. Instead, IPv6 has been conceived to be an evolutionary step forward from IPv4, and interoperate within a network containing a mixture of IPv4 and IPv6 devices. Because IPv6 is deployed gradually and needs to interoperate with IPv4 devices, a way had to be found to route IPv4 packets across IPv6 nodes. This is accomplished using tunneling. An IPv6 tunnel functions like a virtual link between two IPv6 nodes. It is essentially a point-to-point link with IPv6 as the link-layer protocol. Each node plays a specific role in the tunnel. The sending node encapsulates the original IPv6 packets inside an IPv4 packet received from other nodes or from itself and forwards the resulting tunnel packets through the tunnel. The receiving node decapsulates the tunnel packets, stripping off the IPv4 header and forwarding the resulting original IPv6 packets towards their destinations (that may be itself). The encapsulating node is called the tunnel entry-point node, and it is the source of the tunnel packets. The decapsulating node is called the tunnel exit-point, and it is the destination of the tunnel packets (Figure 10-1).
original packet IPv6 payload Transport IPv6 layer hdr header IPv6 payload tunnel packet Transport IPv6 hdr layer hdr IPv4 payload tunnel entrypoint node IPv6 over IPv4 tunnel tunnel exitpoint node destination of original packets IPv4 header
source of original packets
IPv6 router
Dual-stack IPv4/IPv6 router
Dual-stack IPv4/IPv6 router
IPv6 router
Figure 10-1. IPv6-over-IPv4 Tunnel
10-1
10

Tunnel Capacity Test
Traffic flows through a tunnel in one direction only. If traffic must flow in both directions between two nodes, two tunnels must be configured, one for each direction. The IxAutomate tests for IPv6 Tunneling are: Tunnel Capacity Test on page 10-2. This test finds how many frames the DUT loses with various numbers of tunnels. Tunnel Frame Loss Test on page 10-9. This test finds how many frames the DUT loses at various frame rates.
Tunnel Throughput Test on page 10-12. This test searches for the maximum
rate at which the DUT receives and forwards frames with no frame loss. In addition, this chapter covers the following topics: Configuring the Protocol and Tunnel Parameters on page 10-17. Sample DUT Configurations on page 10-26.

This section covers the following topics: Overview on page 10-2. Configuring the Test Parameters on page 10-3. Pass/Fail Criteria on page 10-4. Test Results on page 10-5. Automatic Address Calculation on page 10-6.
Overview
This test determines the maximum number of IPv6/IPv4 tunnels that the DUT can support without frame loss. This test uses pairs of ports with one-to-one traffic mapping, that is, one port transmits to one receive port. You can specify the number of frames to transmit, the transmit rate, and the number of tunnels with which to test for each trial. The test begins by checking the links state on ports to ensure that all the links are up. The transmit and receive ports then ARP to learn the IP address of their corresponding DUT ports. Each receive port then establishes a tunnel with its corresponding DUT port. Starting with the initial tunnel load (the number of tunnels configured for the test), the test transmits the specified number of frames, counts the received number (the number that the DUT can forward). If the DUT is unable to forward all the frames, the test decreases the number of tunnels and transmits again. This process continues until the test finds a tunnel capacity at which the DUT can forward all the frames it receives. The test results display the frame loss for various tunnel loads for each frame size.
10-2

For IPv6 tunneling, multiple ISATAP tunnels may be used per port. You can specify the maximum number of tested tunnels, but it can be a number greater than the number of Tx-Rx pairs for ISATAP tunnels. For other tunnel types, there is no change. The number of tunnels per port is calculated via this formula:
Maximum number of Tunnels Tunnels per port = ----------------------------------------------------------------------Number of TxRx pairs
Because the Number of TxRx pairs might not be a factor of Maximum number of Tunnels, the first ports can each have an extra tunnel.
sources of IPv6 packets tunnel exit-point node and destination of IPv6 packets
tunnel entrypoint node
IPv6 over IPv4 tunnels
DUT Dual-stack IPv4/IPv6 router
simulated dual-stack IPv4/IPv6 routers
IPv6 packets sources of IPv6 packets DUT tunnel exit-point nodes and destinations of IPv6 packets
IPv4 / IPv6 DUT as tunnel entrypoint node
IPv6 / IPv4 tunnels
IPv6 payload ecapsulated within IPv4 packets (Encapsulation at DUT depicted)
Figure 10-2. IPv6 Tunnel Capacity Test
Configuring the Test Parameters
Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. For more details, see Learning Frames Parameters on page 10-4. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Protocol and Tunnel Setup: see Configuring the Protocol and Tunnel Parameters on page 10-17. Run parameters: see Table 10-2.
10-3
10

Tunnel Capacity parameters: see Tunnel Capacity Test Parameters on page 10-4.
Learning Frames Parameters

Table 10-1. Parameter Wait Time Before Transmit (ms) Wait Time After Transmit (ms) Learning Frames Parameters Description The number of milliseconds (ms) to wait before beginning to transmit the frames (default = 0). The number of milliseconds (ms) to wait after the frames are transmitted (default = 1000).
Tunnel Capacity Test Parameters

Table 10-2. Parameter Duration Tunnel Capacity Test Parameters Description The duration of the test in hours, minutes, and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to run. It may be necessary to run several trials of the test to verify the results for consistency. The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The percentage of transmitted packets that can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Staggered Transmit If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports at the same time.
No. of Trials
Max Rate
Loss Tolerance
Pass/Fail Criteria
10-4

Table 10-3. Parameter Pass Criteria
Tunnel Capacity Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of tunnels at which the DUT can forward all the received frames (with a frame loss within the acceptable tolerance). Pass: If the number of tunnels was equal to or greater than the number you entered. Fail: If the number of tunnels was lower than the number you entered.
Tunnel Capacity
Sequence Errors
The number of frames received with sequence errors. You can select either of these two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was equal to or lower than the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered.
CRC Errors
The number of frames received with CRC errors. You can select either of these two methods to calculate the CRC errors: Average/Port: The test averages the frames received with CRC errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with CRC errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with CRC errors was less than or equal to the number you entered. Fail: The number of frames received with CRC errors was greater than the number you entered
Test Results
Table 10-4 describes the Tunnel Capacity test results.
10-5
10

Table 10-4. Result TxFrames RxFrames TxTput %TxTput Loss SeqErrors
Tunnel CapacityTest Results Description Number of frames transmitted Number of frames received Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum port speed Percentage of frames transmitted, but not received Number of frames received with sequence errors Number of frames received with CRC errors Total number of CRC errors for all frames
Integrity Frames Integrity Errors
Automatic Address Calculation
When the ISATAP or the 6to4 addresses are calculated, the specific ISATAP or 6to4 bits are automatically calculated by IxAutomate from the IPv4 address. For example, you can set 1 as the interfaceId for an ISATAP address, and IxAutomate attaches the proper 0000:5EFE:IPv4 Address suffix. The addresses are allocated and removed in a round-robin manner, because this minimizes the difference between ports and removes the last ports if frame loss is high enough. The user specified load rate is applied to each Tx port and divided equally between all the tunnels applied to that port. Therefore, after the number of tunnels is decreased, the remaining tunnels are tested with a greater load rate. For more details, refer to the following topics: Multiple Hosts per Port on page 10-6. Multiple Subnets per Port on page 10-8.
Multiple Hosts per Port

For every subnet associated with each port, a number of sequential addresses is calculated. Because the host belongs to the same subnet, the DUT address is the same for all addresses. You can specify the first IPv4/IPv6 Source/Gateway address. For more details on how the sequential addresses are calculated, refer to the following example.
10-6

----- Calculated Addresses ----** ipAddresses ** ipAddresses(1,2,1) = 192.101.1.100 192.101.1.101 192.101.1.102 ipAddresses(1,2,2) = 192.101.2.100 192.101.2.101 192.101.2.102 ipAddresses(1,2,3) = 192.101.3.100 192.101.3.101 192.101.3.102 ipAddresses(1,2,4) = 192.101.4.100 192.101.4.101 192.101.4.102 ** ipDUTAddresses ** ipDUTAddresses(1,2,1) = 192.101.1.1 192.101.1.1 192.101.1.1 ipDUTAddresses(1,2,2) = 192.101.2.1 192.101.2.1 192.101.2.1 ipDUTAddresses(1,2,3) = 192.101.3.1 192.101.3.1 192.101.3.1 ipDUTAddresses(1,2,4) = 192.101.4.1 192.101.4.1 192.101.4.1 ** ipV6Addresses ** ipV6Addresses(1,2,1) = 2008::1:0:5efe:c065:164 2008::1:0:5efe:c065:165 2008::1:0:5efe:c065:166 ipV6Addresses(1,2,2) = 2008::2:0:5efe:c065:264 2008::2:0:5efe:c065:265 2008::2:0:5efe:c065:266 ipV6Addresses(1,2,3) = 2008::3:0:5efe:c065:364 2008::3:0:5efe:c065:365 2008::3:0:5efe:c065:366 ipV6Addresses(1,2,4) = 2008::4:0:5efe:c065:464 2008::4:0:5efe:c065:465 2008::4:0:5efe:c065:466 ** ipV6DUTAddresses ** ipV6DUTAddresses(1,2,1) = 2008:0:0:1:0:0:0:1 2008:0:0:1:0:0:0:1 2008:0:0:1:0:0:0:1 ipV6DUTAddresses(1,2,2) = 2008::2:0:0:0:1 2008::2:0:0:0:1 2008::2:0:0:0:1 ipV6DUTAddresses(1,2,3) = 2008::3:0:0:0:1 2008::3:0:0:0:1 2008::3:0:0:0:1 ipV6DUTAddresses(1,2,4) = 2008::4:0:0:0:1 2008::4:0:0:0:1 2008::4:0:0:0:1 --------------------------------
If the current iteration was not enough, the current number of tunnels is decreased, the addresses are recalculated and a new iteration started, unless the current number of tunnels is not too low. For more details, refer to Figure 10-3, where A and B are two Tx ports.
Figure 10-3. Example of Iterations for Multiple Hosts per Port
The compatibility with the old behavior is preserved because, when frame loss is high, some ports are not used anymore. In this example, see port B on iteration 6.
10-7
10

Multiple Subnets per Port

The addresses for the automatic map are incremented in a round-robin manner. You can specify the first IPv4/IPv6 Source/Gateway addresses. The address allocation is done as in the following example:
----- Calculated Addresses ----** ipAddresses ** ipAddresses(1,2,1) = 192.101.1.100 192.101.5.100 192.101.9.100 ipAddresses(1,2,2) = 192.101.2.100 192.101.6.100 192.101.10.100 ipAddresses(1,2,3) = 192.101.3.100 192.101.7.100 192.101.11.100 ipAddresses(1,2,4) = 192.101.4.100 192.101.8.100 192.101.12.100 ** ipDUTAddresses ** ipDUTAddresses(1,2,1) = 192.101.1.1 192.101.5.1 192.101.9.1 ipDUTAddresses(1,2,2) = 192.101.2.1 192.101.6.1 192.101.10.1 ipDUTAddresses(1,2,3) = 192.101.3.1 192.101.7.1 192.101.11.1 ipDUTAddresses(1,2,4) = 192.101.4.1 192.101.8.1 192.101.12.1 ** ipV6Addresses ** ipV6Addresses(1,2,1) = 2008::1:0:5efe:c065:164 2008::5:0:5efe:c065:564 2008::9:0:5efe:c065:964 ipV6Addresses(1,2,2) = 2008::2:0:5efe:c065:264 2008::6:0:5efe:c065:664 2008::a:0:5efe:c065:a64 ipV6Addresses(1,2,3) = 2008::3:0:5efe:c065:364 2008::7:0:5efe:c065:764 2008::b:0:5efe:c065:b64 ipV6Addresses(1,2,4) = 2008::4:0:5efe:c065:464 2008::8:0:5efe:c065:864 2008::c:0:5efe:c065:c64 ** ipV6DUTAddresses ** ipV6DUTAddresses(1,2,1) = 2008:0:0:1:0:0:0:1 2008::5:0:0:0:1 2008::9:0:0:0:1 ipV6DUTAddresses(1,2,2) = 2008::2:0:0:0:1 2008::6:0:0:0:1 2008::a:0:0:0:1 ipV6DUTAddresses(1,2,3) = 2008::3:0:0:0:1 2008::7:0:0:0:1 2008::b:0:0:0:1 ipV6DUTAddresses(1,2,4) = 2008::4:0:0:0:1 2008::8:0:0:0:1 2008::c:0:0:0:1 --------------------------------
Refer to Figure 10-4 for more details on iterations for multiple subnets per port.
Figure 10-4. Example of Iterations for Multiple Subnets per Port
The compatibility with the old behavior is preserved because, when frame loss is high, some ports are not used anymore. In this example, see port B on iteration 6.
10-8

Tunnel Frame Loss Test

This section covers the following topics: Overview on page 10-9. Configuring the Test Parameters on page 10-10. Pass/Fail Criteria on page 10-11. Test Results on page 10-12.
Overview
This test determines how many frames the DUT loses at various frame rates. It looks for the maximum frame rate without frame loss. This test uses IPv6 tunnels with pairs of ports with one-to-one traffic mapping; one port transmits to one receive port. You can specify the number of frames to transmit, the initial transmit rate, and the percentage of decrease in the frame rate (the Granularity parameter) for each iteration. The test begins by checking the links state on ports to ensure that all the links are up. The transmit and receive ports then ARP to learn the IP address of their corresponding DUT ports. Each receive port then establishes a tunnel with its corresponding DUT port. Starting with the initial frame rate, the test transmits the specified number of frames, counts the received number (the number that the DUT can forward). If the DUT is unable to forward all the frames, the test decreases the frame rate and transmits again. This test continues until it finds a rate at which the DUT can forward all the frames it receives. The results of the test display the frame loss for various rates for each frame size.
10-9
10

source of IPv6 packets
tunnel entrypoint node DUT Dual-stack IPv4/IPv6 router IPv6 over IPv4 tunnel
tunnel exit-point node and destination of IPv6 packets
simulated dual-stack IPv4/IPv6 router
IPv6 packets
DUT tunnel exit-point node and destination of IPv6 packets IPv6 / IPv4 tunnel
Figure 10-5. IPv6 Tunnel Frame Loss Test
Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Protocol and Tunnel Setup: see Configuring the Protocol and Tunnel Parameters on page 10-17. Run parameters: see Table 10-5.
Tunnel Frame Loss Test Parameters Description The number of trials to run. It may be necessary to run several trials of the test to verify the results for consistency. Number of frames the test transmits at each iteration. The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate.
Table 10-5. Parameter No. of Trials
No. of Frames Max Rate
10-10

Table 10-5. Parameter Granularity
Tunnel Frame Loss Test Parameters (Continued) Description Percentage of decrease in the frame rate for each iteration. Fine = 1% Coarse = 10%
Staggered Transmit
If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously.
Pass/Fail Criteria
Table 10-6 lists the pass/fail criteria for this test:

Table 10-6. Parameter Pass Criteria Tunnel Frame Loss Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
10-11
10

Tunnel Throughput Test
Table 10-6. Parameter CRC Errors
Tunnel Frame Loss Test - Pass/Fail Criteria (Continued) Description The number of frames received with CRC errors. You can select either of these two methods to calculate the CRC errors: Average/Port: The test averages the frames received with CRC errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with CRC errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with CRC errors was less than or equal to the number you entered. Fail: The number of frames received with CRC errors was greater than the number you entered.
Test Results
Table 10-7 describes the Tunnel Frame Loss test results.

Table 10-7. Result TxFrames RxFrames Loss TxTput Integrity Frames Integrity Errors Tunnel Frame Loss Test Results Description Number of frames transmitted Number of frames received Percentage of frames transmitted, but not received Transmit throughput, in frames per second (f/s) Number of frames received with CRC errors Total number of CRC errors for all frames

Overview
This test determines the maximum No Drop Rate when running traffic over IPv6/ IPv4 tunnels. Frames are initially sent at a user-specified rate, generally the maximum theoretical rate based on the speed of the port. If the DUT fails to forward all the frames, the test re-transmits at successively lower rates until the DUT forwards all the frames. It then searches for a rate
10-12

between the last two successful rates until it finds the highest rate at which the DUT forwards all the frames. The setting for the Binary Search parameter determines how the test searches for a new rate. If you set this field to Per-Port, the binary search algorithm treats each receive port separately. If the test must change the transmit rate, it changes it only for specific ports. If you set this field to Linear, the binary search algorithm treats all receive ports as a group. If the test must change the transmit rate, it changes it for all ports.
The test begins by checking the links state on ports to ensure that all the links are up. The transmit and receive ports then ARP to learn the IP address of their corresponding DUT ports. Each receive port then establishes a tunnel with its corresponding DUT port. If the test performs the first iteration using the binary search algorithm and no frames are received, then a second iteration is performed; after that, if no frames are received, the test stops; otherwise, the binary search algorithm continues. This test is configured with a one-to-one traffic mapping. The results of the test show the throughput rates, in frames per second (f/s), obtained for each frame size. The results also show the average throughput rates for all the trials.
tunnel exit-point node and destination of IPv6 packets
tunnel entrypoint node DUT Dual-stack IPv4/IPv6 router
IPv6 over IPv4 tunnel
simulated dual-stack IPv4/IPv6 router
IPv6 packets
DUT tunnel exit-point node and destination of IPv6 packets IPv6 / IPv4 tunnel
Figure 10-6. IPv6 Tunnel Throughput Test
10-13
10

Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Protocol and Tunnel Setup: see Configuring the Protocol and Tunnel Parameters on page 10-17. Run parameters: see Table 10-8.
Tunnel Throughput Test Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to run. It may be necessary to run several trials of the test to verify the results for consistency. The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The number of protocol-level addresses used on each receive port. The percentage of transmitted packets that can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Staggered Transmit If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports at the same time.
No. of Trials
Max Rate
Addresses per Rx Port Loss Tolerance
10-14

Tunnel Throughput Test Parameters (Continued) Description Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the binary search algorithm searches each port pair (transmit and receive port) separately. A rate change on one port does not affect the others. If you set this field to Linear, the binary search algorithm searches all port pairs together, as a group. A rate change applies to all port pairs.
Binary Search
Calibrate Latency
Pass/Fail Criteria

Table 10-9. Parameter Pass Criteria Tunnel Throughput test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
10-15
10

Table 10-9. Parameter Latency
Tunnel Throughput test - Pass/Fail Criteria (Continued) Description Amount of time required by the DUT to forward frames. To specify the unit of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Sequence Errors
The number of frames received with sequence errors. You can select either of these two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the biggest number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was less than or equal to the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered.
CRC Errors
The number of frames received with CRC errors. You can select either of these two methods to calculate the CRC errors: Average/Port: The test averages the frames received with CRC errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the biggest number of frames received with CRC errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with CRC errors was less than or equal to the number you entered. Fail: The number of frames received with CRC errors was greater than the number you entered
Test Results
Table 10-10 describes the Tunnel Throughput test results.
10-16

Configuring the Protocol and Tunnel Parameters
Table 10-10. Tunnel Throughput Test Results Result TxTput RxFrames Loss %TxTput AvgLatency MinLatency MaxLatency SeqErrors Integrity Frames Description Transmit throughput, in frames per second (f/s) Number of frames received Percentage of frames transmitted, but not received Throughput, as a percentage of the theoretical maximum port speed Average latency, in nanoseconds (ns) Shortest latency recorded, in nanoseconds (ns) Longest latency recorded, in nanosecond (ns) Number of frames received with sequence errors Number of frames received with CRC errors

To configure the protocol and tunnel setup parameters for the Tunneling tests, you can use the controls in the Test Setup window and in the Traffic Setup window. Table 10-11 describes the protocol and tunnel parameters you need to set for your test.
Table 10-11. Tunnel Setup Parameters Parameter Test Setup Parameters Tunnel Configuration Select the type of tunnel configuration the Ixia ports use. You can select Automatic or Manual tunnel configuration. Automatic: If you select Automatic tunnel configuration, the Ixia ports use the protocol selected in the Address Type field to contact the DUT and automatically create tunnels. The DUT must be configured to support automatic tunnel creation using the same protocol. Manual: If you select Manual tunnel creation, you must create the tunnels manually on the DUT based on the addresses you use for the Ixia and DUT ports. See Figure 10-7 on page 10-21 for an example of how the test assigns addresses. Description
10-17
10

Table 10-11. Tunnel Setup Parameters (Continued) Parameter Address Type Description Select the type of transition mechanism used to discover the link-local addresses and set up the tunnels. The DUT must be configured to use the same protocol. You can select from among the following mechanisms: ISATAP: Intra-Site Automatic Tunnel Addressing Protocol is a protocol for automatically creating IPv6/IPv4 tunnels. The Ixia ports use ISATAP to query the DUT to obtain address and routing information. When the Ixia transmit ports send packets to the DUT, ISATAP routes the packets over the correct tunnel to the destination (the Ixia receive ports) 6to4: the 6to4 protocol uses a unique routing prefix for each end-user site that carries an IPv4 tunnel endpoint address. ipV4Compatible: If you select IPv4 Compatible, the Ixia ports use an address composed of a 96-bit prefix of all zeros followed by an IPv4 address in the lower 32 bits. Encapsulation Configuration Select the point in the test network where encapsulation occurs. Ixia Tx port: If you select the Ixia transmit port as the encapsulation point, the DUT receives IPv4 packets that contain an IPv6 payload. In this scenario, Ixia transmit port functions as the entry point to a tunnel and the DUT functions as the exit point. See Figure 10-8 on page 10-22. DUT: If you select the DUT as the encapsulation point, the DUT receives native IPv4 packets from the transmit port. It must encapsulate them in IPv4 packets and forward them over the tunnel to the receive port. See Figure 10-9 on page 10-23. Protocol Configuration Capacity Parameters Tunnel Step Enter the number of tunnels that are created or torn down for each trial. If the test functions by increasing the number of tunnels, this parameter specifies the number of tunnels added for each trial, up to the Maximum Tunnels value. If the test functions by decreasing the number of tunnels, this parameter specifies the number of tunnels torn down for each trial, down to the Minimum Tunnels value. If the number of tunnels created during the test is static, this parameter is ignored. Payload Protocol IPv6 Tunnel Protocol IP
10-18

Table 10-11. Tunnel Setup Parameters (Continued) Parameter Minimum Tunnels Maximum Tunnels Per Port Mapping Multiple Hosts Multiple Subnets Enter the number of hosts from the same subnet per port. Enter the number of subnets with a single host each, per port. Description Enter the minimum number of tunnels to create. Enter the maximum number of tunnels to create.
Traffic Setup Parameters IP Address Settings First Port Source Address Enter the IP address to apply to the first Ixia port. The test uses this address as the source IP address.
First Port DUT Address Enter the IP address of the first DUT port. The test uses this address as the destination IP address. Mask Width Octet to Auto Increment Increment Gateway IP Address Specify the width, in bits, of the subnet mask applied to the IP addresses. The default is 24. Select the octet in the First Port Source and First Port DUT Address fields that the test increments to generate additional addresses. If you check this box, the test increments the First Port DUT Address to generate additional addresses for the DUT. If you do not check this box, the test uses the First Port DUT Address as the destination address for all packets going to the DUT. Enabling or disabling this control also enables or disables the Increment DUT IP Address control. IPv6 Address Settings First Port Source Address This field displays the IPv6 address that is applied to the first Ixia port. To configure this address, click Encode, then see Table 10-12 on page 10-24.
First Port DUT Address This field displays the IPv6 address the test expects to find on the first DUT port. To configure this address, click Encode, then see Table 10-12 on page 10-24.
10-19
10

Table 10-11. Tunnel Setup Parameters (Continued) Parameter Increment Field Description Select the field in the Ixia and DUT IPv6 addresses that the test increments to generate addresses for the second and subsequent Ixia and DUT ports. The fields that you can select are: Prefix Length Increment DUT IP Address Top-level aggregation ID field Next-level aggregation ID field Site-level aggregation ID field Subnet ID Interface ID
Specify the length of the prefix of the Ixia and DUT IPv6 addresses. If you check this box, the test increments the First Port DUT Address to generate additional addresses for the DUT. If you do not check this box, the test uses the First Port DUT Address as the destination address for all packets going to the DUT. Enabling or disabling this control also enables or disables the Increment Gateway IP Address control.
10-20

IPv4 First Port Source Address: First Port DUT Address: Octet to Auto Increment: Increment Gateway IP: 1.1.1 1.1.2 1.1.3 198.18.1.100 198.18.2.100 198.18.3.100 198.18.1.1 DUT 198.18.4.1 198.18.1.100 198.18.1.1 3 Yes
198.18.2.1 198.18.3.1
1.1.4
198.18.4.100
IPv6 First Port Source Address: First Port DUT Address: Increment Field: Prefix Length: Increment DUT IP Address: 2000:0:0:1:0:0:0:100 2000:0:0:1:0:0:0:1 Site-Level Aggregation ID 16 Yes
1.1.1 1.1.2 1.1.3
2000:0:0:1:0:0:0:100 2000:0:0:2:0:0:0:100 2000:0:0:3:0:0:0:100 2000:0:0:4:0:0:0:100 2000:0:0:1:0:0:0:1 DUT 2000:0:0:3:0:0:0:1 2000:0:0:4:0:0:0:1
2000:0:0:2:0:0:0:1
1.1.4
Figure 10-7. Address Incrementing
10-21
10

source of IPv4 packets with IPv6 payload AND tunnel entry-point node IPv4 packets Tunnel
tunnel exitpoint node
destination of IPv6 packets
DUT Decapsulation of IPv4 packets Rx port
Tx port
source of IPv4 packets with IPv6 payload
IPv4 packets Tunnel DUT Decapsulation of IPv4 packets
tunnel exit-point node AND destination of IPv6 packets
IPv6 packets
Figure 10-8. Encapsulation Configuration - at Ixia Tx Port
10-22

tunnel entrypoint node DUT
tunnel exit-point node AND destination of IPv6 packets
Tx port
Encapsulation of IPv6 by IPv4
Tunnel
Rx port
IPv6 packets
DUT tunnel exit-point node AND destination of IPv6 packets Tunnel
tunnel entrypoint node Encapsulation of IPv6 by IPv4
Figure 10-9. Encapsulation Configuration - at DUT
10-23
10

Figure 10-10.IPv6 Address Windows Table 10-12. IPv6 Address Parameters by Prefix Type Parameter Global Unicast
Description
Global unicast addresses are globally routable and reachable on the IPv6 portion of the Internet. They are equivalent to public IPv4 addresses. Global addresses are configured by router advertisement. Enter the Top-Level Aggregation (TLA) ID. TLA IDs are assigned by IANA for Sub-TLA allocation. TLA IDs typically identify a high-level ISP.
Top-Level Aggregation ID
Reserved
This field is reserved for future use to allow an increase in either the TLA ID or the NLA ID fields. It is normally set to 0 (zero). Enter the Next-Level Aggregation (NLA) ID. NLA IDs typically identify mid-level ISPs.
Next-Level Aggregation ID
10-24

Table 10-12. IPv6 Address Parameters by Prefix Type (Continued) Parameter Site-Level Aggregation ID
Description
Enter the Site-Level Aggregation (SLA) ID. SLA IDs identify the end-user site. The address prefix for end-user sites is usually supplied by the ISP that provides their IPv6 service.
Interface ID
Enter the Interface ID. The Interface ID is usually generated from the interface LAN address. For example, for an Ethernet interface, the Interface ID is created by taking the first three bytes of the Ethernet MAC address, followed by FFFE, followed by the last three bytes of the Ethernet MAC address, and then performing an exclusive-or function of the result with 0200:0000:0000:0000. Because Ethernet addresses are globally unique, this generates a unique IPv6 address.
Link Local Unicast Interface ID
Link-local addresses are used to communicate between hosts on the link. Enter the Interface ID. See Interface ID in this table for a description of how the Interface ID is usually created. Site-local addresses are used between nodes that communicate with other nodes in the same site. Site-local addresses are configured by router advertisement. Enter the Interface ID. See Interface ID in this table for a description of how the Interface ID is usually created. Enter the Subnet ID. This field allows you to configure all bits of the IPv6 address. Enter the complete IPv6 address.
Site Local Unicast
Interface ID
Subnet ID User Defined User Defined
10-25
10

Sample DUT Configurations

This section contains examples of Cisco routers configured as DUTs for IPv6 Tunneling tests. You can use these examples as a guide to help you configure your own DUTs: Automatic Tunnel Configuration on page 10-26. Manual Tunnel Configuration on page 10-29.
Caution: Please take all appropriate precautions when using these configuration examples. If you are unsure as to how to use the configuration or its possible effect on your DUT or network, please seek appropriate assistance. Ixia cannot be responsible for any damage that use of the configuration causes to your DUT or network.
Automatic Tunnel Configuration
Automatic Tunneling Configuration - 6to4 protocol - Ingress interface Tunnel0 no ip address no ip redirects ipv6 address 3002::/16 tunnel source FastEthernet3/0/1 tunnel mode ipv6ip 6to4 interface FastEthernet3/0/1 ip address 198.18.1.1 255.255.255.0 no ip mroute-cache full-duplex ipv6 enable no cdp enable interface FastEthernet3/1/0 no ip address no ip mroute-cache full-duplex ipv6 address 2000:0:0:2::1/112 no cdp enable ip rsvp basdwidth 75000 75000
10-26

Automatic Tunneling Configuration - 6to4 protocol - Egress interface Tunnel2002 no ip address no ip redirects ipv6 address 2002:C612:0201::1/128 tunnel source FastEthernet3/1/0 tunnel destination 198.18.2.100 tunnel mode ipv6ip 6to4 interface FastEthernet3/0/1 no ip mroute-cache full-duplex ipv6 enable no cdp enable interface FastEthernet3/1/0 ip address 198.18.2.1 255.255.255.0 no ip mroute-cache full-duplex no cdp enable ip rsvp basdwidth 75000 75000 ipv6 route 2002::/16 Tunnel2002
Automatic Tunneling Configuration - IPv4 compatible protocol - Ingress interface Tunnel0 no ip address no ip redirects tunnel source FastEthernet3/0/1 tunnel mode ipv6ip auto-tunnel interface FastEthernet3/0/1 ip address 198.18.1.1 255.255.255.0 no ip mroute-cache full-duplex ipv6 enable no cdp enable interface FastEthernet3/1/0 no ip address no ip mroute-cache full-duplex ipv6 address 2000:0:0:2::1/112 no cdp enable ip rsvp basdwidth 75000 75000
10-27
10

Automatic Tunneling Configuration (Capacity test) - IPv4 compatible protocol - Egress interface Tunnel4 no ip address ipv6 address 3002::/16 tunnel source FastEthernet3/1/0 tunnel mode ipv6ip auto-tunnel interface FastEthernet3/0/1 no ip address no ip mroute-cache full-duplex ipv6 enable no cdp enable interface FastEthernet3/1/0 ip address 198.18.2.1 255.255.255.0 no ip mroute-cache full-duplex no cdp enable ip rsvp basdwidth 75000 75000
10-28

Manual Tunnel Configuration

Manually-configured Ingress tunnel
IPv4 address on FE 3/0/1: 198.18.1.1 Tunnel destination DUT
IPv6 address on Ixia Rx port: 2000:0:0:2::100
Tx
Tunnel source
IPv6 address on FE 3/1/0: 2000:0:0:2::1
Rx
IPv4 address: 198.18.1.100 Internal IPv6 addresses: ---------------------------------Source: 2000:0:0:1::100 Dest: 2000:0:0:2::100
DUT configuration: -----------------------------------------------------------------------tunnel2 addr 3000://112 source FE 3/0/1 dest 198.18.1.100 mode fe 3/0/1 ipaddr 198.18.1.100 fe 3/1/0 ipv6addr static route ipv6route 2000:0:0:2::1 2000::/16 tunnel
10-29
10

Manually-configured Egress tunnel IPv4 address on Ixia Rx port: 198.18.4.100 Tunnel destination
IPv6 address on FE 3/1/1: 2001:0:0 ::1
Tunnel source DUT Tx IPv6 address range on Tx port: 2001:0:0:1:100 to 2001:0:0:2:100 IPv4 address on FE 4/1/0: 198.18.4.1
Rx
DUT configuration: -----------------------------------------------------------------------tunnel2 addr source dest mode 3001::/112 FE 4/1/0 198.18.4.100 ipv6ip 2001:0:0:1:1/112
fe 3/1/1 ipv6addr fe 4/1/0 ip
198.18.4.1 2000::/16 tunnel2
static route ipv6route
10-30
11
Chapter 11:
Quality of Service (QoS) Test Suite

Run Parameters on page 11-1. VLAN Parameters on page 11-1. Many-to-One Test on page 11-6. One-to-Many Test on page 11-7. Flow Ratio Test on page 11-9.
This chapter describes the tests in the Quality of Service (QoS) suite:
Run Parameters
VLAN Parameters
The VLAN Parameters are described in Table 11-2 on page 11-3.
Table 11-1. Field Duration Quality of Service - Run Parameters Usage The duration of the test in hours, minutes and seconds that is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. The maximum transmission frame rate The number of frames to transmit in a single burst.
No. of Trials
Max Tx Frame Rate Burst Size(# of frames)
11-1
11

VLAN Parameters
Table 11-1. Field
Quality of Service - Run Parameters (Continued) Usage The Inter-Burst gap, expressed as a number of frames. This allows you to choose if you want to calculate the latency or not for your test. You can choose one of the following options: None it means that you do not want to calculate the latency value for your test Cut-Through you choose to calculate latency using the Cut Through method: that is, the delay between the time the first bit of the test frame leaves the Ixia TX port and the time it arrives on the Ixia RX port. Cut Through is normally used with switches and other devices that operate using packet header information. 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 you choose to calculate latency using the Store and Forward method: that is, the delay between the time the last bit of the test frame leaves the Ixia TX port and the time its first bit arrives on the Ixia RX port. Store and Forward is normally used with routers and other devices that operate on the contents of the entire packet. The last transmitted data bit 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 latency is calculated by first determining the Cut Through delay and then substracting the frame length time. Inter-Arrival Time you can choose to calculate latency using the Inter-Arrival Time method: that is, the time between packet arrivals are compared. In this case, when a packet is received, the timestamp of the previous packet is subtracted from the current timestamp. The interval between the timestamps is the jitter, and it is recorded for statistical purposes.
Frames per burst gap Latency Calculation
Calibrate Latency
IP Precedence (priority bits) Staggered Transmit
If set, the priority bits are set in the precedence portion of the IP header. When streams are applied to a number of ports at a time, the start time between the ports is staggered by approximately 27 ms.
11-2

VLAN Parameters
Table 11-1. Field
Quality of Service - Run Parameters (Continued) Usage The percentage rate by which to increase each QoS rate for the Many-to-One and Flow Ratio tests. This parameter is found in the Priority Parameters dialog (see Figure 11-1 on page 11-3) for the Flow Ratio test. The number of iterations to run for the Many-to-One test. Each iteration increases the rates found in the Priority Parameters (see Figure 11-1 on page 11-3) by the amount of the Increment Step value. This value is found in the Priority Parameters dialog for the Flow Ratio test.
Increment Step
No. of Iterations
Table 11-2 describes the VLAN parameters available in the Traffic Setup window (Frame Data section).
Table 11-2. Parameter Enable 802.1q Tag Adjust for Tags First Vlan ID Increment Vlan ID 802.1p (priority bits) Enable ISL Tag QoS VLAN Parameters Description Selects the Vlan type based on the 802.1q standard. Either this or Enable ISL Tag should be checked. If you check this box, the test compensates for a DUT that strips VLAN tags. The first VLAN tag to be assigned Increments the VLAN IDs between ports. If checked, the priority bits are set in the precedence portion of the IP header. Selects the Vlan type based on the Cisco ISL standard. Either this or Enable 802.1q Tag should be checked.
The Priority Parameters are available in the Test Setup window (Figure 11-1).
Figure 11-1. Priority Parameters
11-3
11

VLAN Parameters
The Priority parameters and the VLAN parameters allow you to specify where the priority bits should be placed in the packet in the IP header, as precedence bits, or in the 802.1p / VLAN header. These flags are independent of the type of interface (MAC vs. IP) selected for the test. In addition, they may be used simultaneously if desired, meaning that you can set both the IP precedence and the VLAN priority bits in the same packet. Depending on which of the following check boxes are enabled, different priority settings are used in the test: the 802.1p (priority bits) check box from the Frame Data section the Enable ISL Tag check box from the Frame Data section the IP ToS Precedence (priority bits)/ DSCP check box from the Test Parameters section
For example, if the Enable 802.1p check box is enabled, the priority used is the L2 CoS field.
Note: You must enable at least one location for the priority bits (in the IP header or in the VLAN header). If neither is checked, the test does not run.
You can set different CoS values, ToS values (IP precedence or DSCP), and the corresponding transmit rate for a single stream. Depending on the map type, oneto-many or many-to-one, these streams are configured each on a separate port or all on a single port.
Table 11-3. Field Layer 2 CoS Layer 3 ToS Byte Rate (%) Priority Parameters Description Usage You can set a value from 0 to 7. The default value is 0. For more information, see Table 11-4. The percentage of maximum frame rate per priority to use in order to run the test.
For the ToS Octet Type field, if you set: the IP Precedence option, you can choose for the Precedence parameter a value in the 0-7 range as representing the level of precedence. the DSCP (Differentiated Service Code Point) option, you can choose for the Mode parameter one of the defined modes available in the drop-down list. The DSCP modes are listed in Table 11-4.
11-4

VLAN Parameters
Table 11-4.
DSCP Defined Modes Description The DSCP value is fixed and the Binary Value and Decimal Value parameters cannot be changed. The default DSCP value is compatible with the default IP precedence value (all zeros).
DSCP Mode Default Mode
Class Selector
It can be set to one of the classes available in the dropdown list. These defined classes are backwards compatible with the IP precedence values (see Table 11-5 on page 11-5). You can choose among three drop precedences (low, medium, high) for each of classes 1-4, totaling 12 assured forwarding (AF) possibilities. The DSCP value is fixed (101110 or 46 in decimal). You can modify either of the Binary Value or the Decimal Value fields. This is the only mode where the value field is editable. The valid values for Binary Value are in the 000000 111111 range; the valid values for Decimal Value are in the 0 - 63 range. Note: If a predefined value is manually entered in Custom mode (for example, 101110 (46 decimal value) - Expedited Forwarding) then it is recognized and appears in the list with the predefined value (for example, DSCP EF, not DSCP 46)
Assured Forwarding
Expedited Forwarding Custom
Table 11-5 lists the Class Selector backward compatibilities with the IP precedence values.
Table 11-5. DSCP Defined Modes - Class Selector Backward Compatibilities DSCP - Binary Value 000 000 00 001 000 00 010 000 00 011 000 00 100 000 00 101 000 00 110 000 00 111 000 00 IP Precedence equivalent 0 1 2 3 4 5 6 7 Purpose Best effort Class 1 Class 2 Class 3 Class 4 Express forwarding Control Control
DSCP - Decimal Value 0 8 16 24 32 40 48 56
11-5
11

Many-to-One Test
Many-to-One Test
The many-to-one QoS test sets up a configuration such that many ports, each with a different priority, sends traffic to a single port. The receive port may be overloaded in order to test the receipt of the highest priority frames. This test supports both MAC and IP layer frames; priority bits may be specified either in the IP precedence bits or in the 802.1p header. Latency may optionally be calculated per priority level. Additionally, the jitter may be calculated, if choosing for Latency Calculation parameter the Inter-Arrival Time option. The test results consist of the transmit and receive rates per priority, loss percentage, and optionally, latency and jitter for each priority per port. IMPORTANT: If both the MAC protocol and the VLANs are enabled for your test, it is required to set at least 60 seconds (s) for the Duration parameter. This time is needed due to automatic operations on the DUT that are required before starting to forward.
Table 11-6. Parameter Pass Criteria Many-to-One Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
11-6

One-to-Many Test
Many-to-One Pass Criteria (Continued) Description Amount of time required by the DUT to forward frames. To specify the unit of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Supported Protocols
Features Required on Ports Transmit port Receive port RxWidePacketGroupMode
MAC, IP, IPX, VLANs
Packet Streams mode
One-to-Many Test
The one-to-many QoS test transmits multiple priorities to multiple receive ports from a single transmit port. The transmit port may be set up as having a different interface speed than the receive ports, that is, 1000 Mb/s transmitting to many 100 Mb/s ports. This test supports both MAC and IP layer frames; priority bits may be specified either in the IP precedence field for Layer 3 QoS or in the 802.1p header for VLAN QoS. The test results consist of the transmit and receive rates per priority, loss percentage, and optionally, jitter, for each priority per port.
Table 11-7. Parameter Pass Criteria One-to-Many Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
11-7
11

One-to-Many Test
One-to-Many Pass Criteria (Continued) Description Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
% Frame Loss
Latency
Supported Protocols
MAC, IP, IPX, VLANs
Packet Streams mode
11-8

Flow Ratio Test
Flow Ratio Test

The Flow Ratio QoS test sets up a configuration such that many ports, each with a different priority, send traffic to a single port. The receive port may be overloaded in order to test the receipt of the highest priority frames. This test supports MAC and IP layer frames; priority bits may be specified either in the IP precedence bits or in the 802.1p header; however, the test may be configured such that each iteration increases or decreases the traffic rate percentage for every priority. Additionally, frames per burst and burst gap can be manipulated to define traffic pattern. Optionally, jitter may be set up to be calculated per priority to obtain the average latency and standard deviation.
Table 11-8. Parameter Pass Criteria Flow Ratio Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered. Latency Amount of time required by the DUT to forward frames. To specify the unit of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
% Frame Loss
11-9
11

Flow Ratio Test
Supported Protocols
MAC, IP, IPX, VLANs
Packet Streams mode
11-10
12
Chapter 12:
Layer 2 VPN Test Suite
This chapter covers the following topics: Overview of the Layer 2 VPN Test Suite on page 12-2. DUT Setup on page 12-2.
The IxAutomate tests for Layer 2 VPNs are: LDP Egress Performance Test on page 12-5 determines the maximum rate at which a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node can strip or 'pop' MPLS labels from incoming packets and forward the resulting traffic with no loss. LDP IMIX Performance Test on page 12-11 determines the frame loss per VC for a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node. The test transmits a mix of frame sizes simultaneously. The DUT can be tested as either an ingress or egress node. LDP Ingress Performance Test on page 12-21 determines the maximum rate at which a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node can apply or 'push' MPLS labels to incoming IP packets and forward the resulting MPLS traffic with no loss. LDP Partially-Meshed Performance Test on page 12-27 determines the frame loss per VC for a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node. The DUT can be tested as either an ingress or egress node:
Martini Sessions Scalability Test on page 12-37 determines the maximum
number of Martini sessions over which a label-switching router (LSR) can forward VPN traffic with no loss. The LSR must create enough VRF tables to support the number of simulated VPNs, establish the required number of Martini sessions, apply labels to the incoming traffic, and then forward the incoming traffic to the correct VPN. Virtual Circuits Scalability Test on page 12-43 determines the maximum number of Virtual Circuits (VCs) a label-switching router (LSR) can support over a single Martini session with no loss. The LSR must apply labels to incoming traffic and forward the traffic over the correct VC to its destination.
12-1
12

Overview of the Layer 2 VPN Test Suite

Layer 2 VPNs are VPNs in which MPLS routes traffic through tunnels across a service provider's existing layer 2 core transport network. Like Layer 3 VPNs, Layer 2 VPNs include the concept of Provider Edge (PE) and Customer Edge (CE) routers. However, their relationship is different in a Layer 2 VPN than it is in a Layer 3 VPN. In a Layer 3 VPN, the PE and CE routers are peers, and the PE router maintains separate routing (VRF) tables for each VPN. In a Layer 2 VPN, the PE and CE routers are not peers, and the PE router does not maintain separate routing tables, Instead, it simply switches incoming traffic onto the correct point-to-point tunnel to move it across the network to another PE router. A Layer 2 MPLS VPN determines reachability through the data plane by using address learning, instead of through the control plane through BGP route exchange as with Layer 3 VPNs. Martini drafts define the methods for establishing the tunnels and encapsulating the traffic. Transport technologies covered by Martini drafts include Ethernet, Frame Relay, ATM, TDM, and PPP/HDLC.
VPN A
CE PE P P
PE
CE
VPN B
VPN B
PE
CE
VPN A
CE CE PE P Customer Edge router Provider Edge router Provider router LSP label Layer 2 links LSPs Tunnel for VPN A Tunnel for VPN B VC label control word layer 2 payload
Figure 12-1. Layer 2 MPLS VPN
DUT Setup
Table 12-1 on page 12-3 lists examples of how to configure a Cisco router as the DUT for the Layer 2 VPN tests. Use these examples as guides to configuring your own DUT. The configuration shown in Table 12-1 on page 12-3 is for a Cisco 7200 and creates a configuration with 2 PE ports and 2 CE ports with 2 VCs on each PE port. For the tests that support a choice of VC distribution (round-robin or consecutive), use the CE port setup that corresponds to the VC distribution you plan to
12-2

DUT Setup
use in the test. For the other tests, use the CE port setup for consecutive VC distribution.
Table 12-1. Commands
Sample Cisco 7200 configuration for Layer 2 VPN tests Description Configure PE port 1
interface FastEthernet2/21 ip address 170.0.1.1 255.255.255.0 ip ospf network broadcast mpls ldp discovery transport-address interface mpls label protocol ldp tag-switching ip interface FastEthernet2/24 ip address 170.0.2.1 255.255.255.0 ip ospf network broadcast mpls ldp discovery transport-address interface mpls label protocol ldp tag-switching ip router ospf 41 log-adjacency-changes network 170.0.1.0 0.0.0.255 area 0 router ospf 42 log-adjacency-changes network 170.0.2.0 0.0.0.255 area 0 interface Loopback0 ip address 10.100.0.1 255.255.255.255
Configure PE port 2
Configure OSPF on PE ports
Configure the DUT loopback address
12-3
12

DUT Setup
Sample Cisco 7200 configuration for Layer 2 VPN tests (Continued) Description Configure CE Ports (Round-robin VC distribution) Note: On a Cisco 6500, the mpls l2transport command is part of the VLAN interface.
interface FastEthernet2/22.1 encapsulation dot1Q 50 mpls l2transport route 7.7.7.1 50 interface FastEthernet2/22.2 encapsulation dot1Q 51 mpls l2transport route 7.7.7.2 52 interface FastEthernet2/23 no ip address mpls label protocol ldp tag-switching ip interface FastEthernet2/23.1 encapsulation dot1Q 52 no mpls l2transport route 7.7.7.2 52 interface FastEthernet2/23.2 encapsulation dot1Q 53 mpls l2transport route 7.7.7.2 53 interface FastEthernet2/22.1 encapsulation dot1Q 50 mpls l2transport route 7.7.7.1 50 interface FastEthernet2/22.2 encapsulation dot1Q 51 mpls l2transport route 7.7.7.1 51 interface FastEthernet2/23 no ip address mpls label protocol ldp tag-switching ip interface FastEthernet2/23.1 encapsulation dot1Q 52 mpls l2transport route 7.7.7.2 52 interface FastEthernet2/23.2 encapsulation dot1Q 53 mpls l2transport route 7.7.7.2 53
Configure CE Ports (Consecutive VC distribution) Note: On a Cisco 6500, the mpls l2transport command is part of the VLAN interface.
12-4

LDP Egress Performance Test

This section covers the following topics: Overview on page 12-5. Configuring the Test Parameters on page 12-6. L2 VPN Parameters on page 12-8. Pass/Fail Criteria on page 12-9. Test Results on page 12-10.
Overview
This test determines the maximum rate at which a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node can strip or 'pop' MPLS labels from incoming packets and forward the resulting traffic with no loss. This test requires two ports, in a one-to-one port mapping: one to simulate a PE router and another to simulate a customer edge (CE) router. The configuration phase of this test proceeds as follows: 1. The port simulating the PE router establishes an OSPF session and advertises a Router Link State Advertisement (RLSA) for a simulated Provider (P) router. The RLSA includes the loopback address of the simulated PE router. 2. An LDP session advertises a Forwarding Equivalence Class (FEC) for the simulated PE router. 3. The tunnel label value is configurable. However, if the DUT encapsulates control traffic with an MPLS label, you must set the Label value to 3 (a null label). Otherwise, the Ixia port interprets the control traffic as data traffic and does not process the packet correctly. 4. A Martini session is established with the DUT. No protocols are established on the CE port because this port's role is to simply receive traffic from the simulated PE router. This port has a layer 2 interface to the DUT. The data validation phase of this test proceeds as follows: The port simulating the PE router transmits unidirectional MPLS traffic at the specified rate. If the packet loss tolerance is exceeded, the test uses a binary search algorithm to calculate a lower rate and then re-transmits the MPLS traffic. The test continues searching for new rates and re-transmitting until it finds a rate at which the DUT does not lose any frames. For each trial, the results show: Lowest, highest, and average latencies Data errors (uses the data integrity feature) Number of small, large, reverse, and total Sequence Errors
12-5
12

Average transmit rate in frames per second (f/s) Average transmit rate as a percentage of port speed
LSP tunnel
Layer 2 VPN traffic
Labeled traffic
MPLS traffic
VPN Customer Edge (CE)
DUT DUT Provider Edge (PE)
LDP OSPF Provider (P)
OSPF Provider Edge (PE)
VPN
Simulated Customer Edge (CE) VPN
Layer 2 VPN traffic
Provider Edge (PE) labeled traffic DUT
MPLS traffic
VPN
Simulated Provider Edge (PE)
OSPF Simulated Provider (P) LSP tunnel LDP
Figure 12-2. Layer 2 VPN LDP Egress Performance Test Scenario
Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 12-2.
Layer 2 VPN LDP Egress Performance Test Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration.
No. of Trials
Pause Before Transmit
12-6

Layer 2 VPN LDP Egress Performance Test Parameters (Continued) Description Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the binary search algorithm searches each port pair (transmit and receive port) separately. A rate change on one port does not affect the others. If you set this field to Linear, the binary search algorithm searches all port pairs together, as a group. A rate change applies to all port pairs.
Binary Search
Calibrate Latency
LDP Parameters No. of VCs Number of Virtual Circuits to establish with the DUT. The DUT must be configured to establish the same number of VCs as the Ixia port. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID. IP address used to establish LDP session with DUT. Internal loopback address on simulated CE router. The DUT must be configured to use this address as a tunnel endpoint. Layer 2 interface to DUT. The setting of this parameter determines the type of validation traffic sent to the DUT. VLAN: If you set this parameter to VLAN, the test transmits VLAN-tagged traffic. Ethernet: If you set this parameter to Ethernet, the test transmits standard Ethernet frames. First VLAN ID Value of the first VLAN tag applied to VLAN-tagged traffic (if L2 Interface Type = VLAN). The DUT must be configured to be on the same VLAN. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. The first label in the range of MPLS labels.
First VC ID
PE Loopback IP Peer IP Address
L2 Interface Type
Max Wait Time
MTU Size
Label Start Value
12-7
12

Layer 2 VPN LDP Egress Performance Test Parameters (Continued) Description
IGP Parameters Interface Network Type OSPF interface network type. If you are using a POS load module, select Point-to-point. If you are using an Ethernet load module, select Broadcast. OSPF area of the simulated CE router
Area ID
MAC Learn Frame Parameters Frequency Determines when the test sends the MAC Learn frames. On Trial: The test sends MAC Learn frames before the start of each trial. Never: The test never sends MAC Learn frames. No. of Frames to Each Host Rate Number of MAC Learn frames sent to each host. Rate at which the test sends MAC Learn frames.
L2 VPN Parameters
When you click the Parameters button, IxAutomate displays the L2 VPN parameters described in Table 12-3.
Table 12-3. Parameter Loss Tolerance L2 VPN Settings Description The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Max Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The initial rate at which the test transmits frames. Enter this value as a number of frames per second. Select the number and type of VLAN tags added to the traffic: VLAN Based: Frames include only a single 802.1Q VLAN tag. QinQ: Frames include an 802.1Q tag and a second VLAN tag added as a service delimiter. Ethernet: Frames are raw Ethernet frames.
Frames/Second Traffic Mode
12-8

L2 VPN Settings (Continued) Description Number of PE routers simulated on each PE port. If you check this box, the test bursts traffic from all transmit ports to one receive port at a time.
Number of PEs per Port Enable Egress Burst Traffic
12-9
12

Pass/Fail Criteria

Table 12-4. Parameter Pass Criteria Layer 2 VPN LDP Egress Performance Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
12-10

Table 12-4. Parameter Data Errors
Layer 2 VPN LDP Egress Performance Test - Pass/Fail Criteria Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors is less than or equal to the value you entered. Fail: The number of frames received with errors is greater than the number you entered.
Test Results
Table 12-5 describes the LDP Egress Performance test results.

Table 12-5. Result TxTput %TxTput DataErrors AvgLatency Low High SmallSeqError Layer 2 LDP Egress Performance Test Results Description Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum. Number of frames received with errors Average latency, in nanoseconds Number of frames with latencies below the average Number of frames with latencies above the average Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold.
12-11
12

LDP IMIX Performance Test
Table 12-5. Result
Layer 2 LDP Egress Performance Test Results Description Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number.
ReverseSeqError
TotalSeqErrors
Combined total of packets with sequence errors of all types.

This section covers the following topics: Overview on page 12-11. Configuring the Test Parameters on page 12-15. Frame Sizes and Weights on page 12-15. L2 VPN Parameters on page 12-19. Pass/Fail Criteria on page 12-19. Test Results on page 12-21.
Overview
This test is similar to the LDP Partially-Meshed Performance Test. Like that test, it determines the frame loss per VC for a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node. The difference between the two tests is that the IMIX Performance test transmits a mix of frame sizes simultaneously. The DUT can be tested as either an ingress or egress node: If the DUT is an ingress node, it must apply or 'push' MPLS labels onto incoming Layer 2 packets and forward the resulting MPLS traffic at the specified transmit rate. If the DUT is an egress node, it must strip or pop the label from incoming MPLS packets and forward the resulting layer 2 traffic at the specified transmit rate.
This test requires at least two Ixia ports, in a one-to-one traffic mapping: one to simulate a PE router and another to simulate a customer edge (CE) router. You can use additional ports to simulate additional PE and CE routers, but the number of simulated PEs must equal the number of simulated CEs. The CE ports have a Layer 2 VLAN interface to the DUT.
12-12

Configuration: CE ports: 1.1.1, 1.1.2, 1.1.3 PE ports: 1.2.1, 1.2.2, 1.2.3 First VC ID: 600 First VLAN ID: 800 No. VCs per PE: 100
1.1.1 VLANs 800 - 899 1.1.2 VLANs 900 - 999 DUT 1.1.3 VLANs 1000 - 1099 VCs 800 - 899 (Consecutive) VCs 602, 605, 608 (Round-robin) VCs 700 - 799 (Consecutive) VCs 601, 604, 607 (Round-robin) VCs 600 - 699 (Consecutive) VCs 600, 603, 606 (Round-robin)
1.2.1
1.2.2
1.2.3
Simulated CE routers
Simulated PE routers
Figure 12-3. LDP IMIX Performance VLAN/VC Distribution
If you use more than two ports, the test maps VLAN IDs to VCs based on the order you add CE and PE ports to the map. For example, consider the following configuration:
Ports 1.1.1, 1.1.2, 1.1.3, 1.1.4
No. VCs per PE 100 First VLAN ID First VC ID 800 600
If you select 1.1.1 as a CE port and 1.1.2 as a PE port and add them to the map, then select 1.1.3 as a CE and 1.1.4 as a PE, the resulting port lists are:
CE 1.1.1 1.1.3 PE 1.1.2 1.1.4
If you select Consecutive VC distribution, the test allocates VCs and VLAN IDs as follows:
CE VLANs PE VCs
1.1.1 1.1.3
800-899 900-999
1.1.2 1.1.4
600-699 700-799
In a Consecutive VC distribution, the frames the DUT receives on one CE-connected port are forwarded out one PE-connected port.
12-13
12

Consecutive VC Distribution Configuration: ---------------------------------------CE ports: 1.1.1, 1.1.2, 1.1.3 PE ports: 1.2.1, 1.2.2, 1.2.3 First VC ID: 600 First VLAN ID: 800 No. VCs per PE: 100 PE Port List port 1 port 2 port 3 port 4 Increasing VC IDs
1.1.1 VLANs 800-899 1.1.2 VLANs 900-999 VCs 700-799 DUT 1.1.3 VLANs 1000-1001 VCs 800-899 VCs 600-699
1.2.1
1.2.2
1.2.3
Figure 12-4. Consecutive VC Distribution
If you select Round-robin VC distribution, the test allocates VCs and VLAN IDs as follows:
CE VLANs PE VCs
1.1.1 1.1.3
800-899 900-999
1.1.2 1.1.4
600, 602, 700, 702, 601, 603, 701, 703,
In a Round-robin VC distribution, the frames the DUT receives on one CE-connected port are forwarded out all its PE-connected ports.
12-14

Configuration: ------------------------------------------CE ports: 1.1.1, 1.1.2, 1.1.3 PE ports: 1.2.1, 1.2.2, 1.2.3 First VC ID: First VLAN ID: No. VCs per PE: 600 800 100 PE Port List
Round-robin VC Distribution port 1 port 2 port 3 port 4 Increasing VC IDs
1.1.1 VLANs 800-899 1.1.2 VLANs 900-999 VCs 601 . . . 701 . . . 801 . . . DUT 1.1.3 VLANs 1000-1001 VCs 602 . . . 702 . . . 802 . . . VCs 600 . . . 700 . . . 800 . . .
1.2.1
1.2.2
1.2.3
Figure 12-5. Round-Robin VC Distribution
The test maps VLAN IDs to VCs consecutively:

VLAN ID 800 801 802 803 8xx 900 901 9xx 1000 1001 1xxx VC 600 601 602 603 6xx 700 701 7xx 800 801 8xx
12-15
12

The configuration phase of this test proceeds as follows: The port simulating the PE router establishes an OSPF session and advertises a Router Link State Advertisement (RLSA) for a simulated network Provider (P) router. The RLSA includes the loopback address of the simulated PE router. An LDP session then advertises a Forwarding Equivalence Class (FEC) for the simulated PE router. The tunnel label value is configurable. However, if the DUT encapsulates control traffic with an MPLS label, you must set the Label value to 3 (an implicit null label). Otherwise, the Ixia port interprets the control traffic as data traffic and does not process the packet correctly. A Martini session is established with the DUT.
No protocols are established on the port simulating the CE router because this port's only function is to generate layer 2 traffic to the VCs advertised by the simulated PE router. For the load testing phase of the test, CE and PE ports both transmit traffic at the specified rate. For each trial, the results show: Frame loss per VC ID for each frame size Lowest, highest, and average latencies Data errors Frame Size: see Frame Sizes and Weights on page 12-15. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 12-15 on page 12-33.
Frame Sizes and Weights
This test includes five predefined frame sizes. You can add more frames sizes, change the sizes of the predefined frames, or delete them. Each frame size has a weight assigned to it. The weights, relative to each other, determine the distribution of frame sizes within the total frames transmitted. For example, in the default configuration, the predefined frames all have the same weight, 1:
Size 64 128 256 Weight 1 1 1
12-16

512 1024
1 1
In this configuration, the test transmits equal numbers of each frame size. If you change one or more of the weights, the test adjusts the numbers of each frame size to match the weights; there will be more higher-weighted frames and fewer lower-weighted frames. The total number of frames does not change. To calculate the distribution of weights, the test uses the formula shown in Figure 12-6.
frame size weight = percent of all frames transmitted total of all weights
Figure 12-6. LDP IMIX Weight Formula
For example, if you change the weights of the predefined frames as follows:
Size 64 128 256 512 1024 Weight 1 2 3 2 1
the distribution of the transmitted frame sizes are the following:

Size 64 128 256 512 1024 Weight 1 2 3 2 1 Distribution 11% 22% 34% 22% 11%
Table 12-6. Parameter Size Weight
Layer 2 VPN LDP IMIX Performance Test Frame Size Parameters Description Enter a frame size to use in the test. You can enter any value supported by the port. Enter a weight for the currently selected frame size. The total weights of all frames must not exceed 2048.
12-17
12

Layer 2 VPN LDP IMIX Performance Test Run Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. Transmit direction. You can select from the following directions: Bidirectional: Each port transmits to every other port. This option tests the DUTs ability to strip or pop MPLS labels from packets going to the CE and while simultaneously applying or pushing MPLS labels packets going to the PE. PE->CE: PE ports transmit only to CE ports. This option tests the DUTs ability to strip or pop MPLS labels and forward them to the CE. CE->PE: CE ports transmit only to PE ports. This option tests the DUTs ability to apply or push MPLS labels onto IP packets and forward the resulting MPLS traffic to the PE.
Tx Direction
No. of Trials
The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10.
Pause Before Tx
Calibrate Latency
LDP Parameters No. of VCs per PE Number of Virtual Circuits each PE is to establish with the DUT. The DUT must be configured to establish the same number of VCs. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID. IP address used to establish LDP session with DUT. Internal loopback address on simulated CE router. The DUT must be configured to use this address as a tunnel endpoint.
First VC ID
12-18

Layer 2 VPN LDP IMIX Performance Test Run Parameters (Continued) Description Method used to distribute VC IDs among two or more ports simulating PE routers. If you select Consecutive, the test distributes ranges of consecutive VC IDs to the PE ports, in the order the ports are listed in the PE port list. If you select Round-robin, the test distributes VC IDs one at a time, cycling through the ports in the order they are listed in the PE port list.
VC ID Distribution
First VLAN ID
Value of the first VLAN tag applied to VLAN-tagged traffic (if L2 Interface Type = VLAN). The DUT must be configured to be on the same VLAN. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. Layer 2 interface to DUT. The setting of this parameter determines the type of validation traffic sent to the DUT. VLAN: If you set this parameter to VLAN, the test transmits VLAN-tagged traffic. Ethernet: If you set this parameter to Ethernet, the test transmits standard Ethernet frames.
Max Wait Time
MTU Size
L2 Interface Type
Label Start Value IGP Parameters Interface Network Type
The first label in the range of MPLS labels.
OSPF interface network type. If you are using a POS load module, select Point-to-point. If you are using an Ethernet load module, select Broadcast. OSPF area of the simulated CE router
Area ID Advanced Parameters Start Reserved VLAN ID
First VLAN ID in reserved range. Some devices reserve a range of VLAN IDs for their own internal use. You can use the Start and End Reserved VLAN ID parameters to define this range. When you run the test, it skips the reserved VLAN IDs when it transmits. Last VLAN ID in reserved range.
End Reserved VLAN ID
12-19
12

Layer 2 VPN LDP IMIX Performance Test Run Parameters (Continued) Description
L2 VPN Parameters
Table 12-8. Parameter Loss Tolerance L2 VPN Settings Description The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Max Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The initial rate at which the test transmits frames. Enter this value as a number of frames per second. Select the number and type of VLAN tags added to the traffic: VLAN Based: Frames include only a single 802.1Q VLAN tag. QinQ: Frames include an 802.1Q tag and a second VLAN tag added as a service delimiter. Ethernet: Frames are raw Ethernet frames. Number of PEs per Port Enable Egress Burst Traffic Number of PE routers simulated on each port. If you check this box, the test bursts traffic on the egress ports.
Pass/Fail Criteria
12-20

Layer 2 VPN LDP IMIX Performance Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Latency
Data Errors
The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors is less than or equal to the value you entered. Fail: The number of frames received with errors is greater than the number you entered.
% Frame Loss
Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
12-21
12

LDP Ingress Performance Test
Test Results
Table 12-10 describes the LDP Partially-Meshed Performance test results.

Table 12-10. Layer 2 LDP IMIX Performance Test Results Result TxTput %TxTput DataErrors AvgLatency Low High Description Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum. Number of frames received with errors Average latency, in nanoseconds Number of frames with latencies below the average Number of frames with latencies above the average

Overview
This test determines the maximum rate at which a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node can apply or 'push' MPLS labels to incoming IP packets and forward the resulting MPLS traffic with no loss. This test requires two ports, using a one-to-one traffic mapping: one to simulate the PE router and another to simulate a customer edge (CE) router. The configuration phase of this test proceeds as follows: 1. The port simulating the PE router establishes an OSPF session and advertises a Router Link State Advertisement (RLSA) for a simulated Provider (P) router. The RLSA includes the loopback address of the simulated PE router. 2. An LDP session then advertises a Forwarding Equivalence Class (FEC) for the simulated PE router. 3. The tunnel label value is configurable. However, if the DUT encapsulates control traffic with an MPLS label, you must set the Label value to 3 (a null label). Otherwise, the Ixia port interprets the control traffic as data traffic and does not process the packet correctly. 4. A Martini session is established with the DUT. No protocols are established on the port simulating the CE router because this port's role is simply to generate layer 2 traffic to the VCs advertised by the simulated PE router. This port has a layer 2 or VLAN interface to DUT.
12-22

The data validation phase of this test proceeds as follows: The port simulating the CE node transmits unidirectional traffic at the specified rate. The type of traffic generated depends on the setting for the L2 Interface Type parameter. If the interface to the PE node is a standard Layer 2 interface (L2 Interface Type = Ethernet), the test generates ordinary Ethernet traffic. If the interface to the PE node is a VLAN interface ((L2 Interface Type = VLAN)), the test generates VLAN-tagged traffic. If the packet loss tolerance is exceeded, the test uses a binary search algorithm to calculate a lower rate and then re-transmits the traffic. The test continues searching for new rates and re-transmitting until it finds a rate at which the DUT does not lose any frames. For each trial, the results show: Lowest, highest, and average latencies Data errors (uses the data integrity feature) Number of small, large, reverse, and total Sequence Errors Average transmit rate, in f/s Average transmit rate as a percentage of port speed
LSP tunnel Labeled traffic Layer 2 VPN traffic Martini session Layer 2 VPN traffic
VPN Customer Edge (CE)
DUT DUT Provider Edge (PE)
LDP OSPF Provider (P) router
LDP OSPF
VPN Provider Edge (PE)
Simulated Customer Edge (CE) VPN
Layer 2 VPN traffic
Provider Edge (PE) Layer 2 VPN traffic

VPN
Labeled traffic
DUT
Simulated Provider Edge (PE)
Sim. Provider (P)
OSPF LSP tunnel Martini session LDP
Figure 12-7. Layer 2 VPN LDP Ingress Performance Test Scenario
12-23
12

Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 12-11 on page 12-23.
Table 12-11. Layer 2 VPN LDP Ingress Performance Test Parameters Parameter Duration Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration. Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the binary search algorithm searches each port pair (transmit and receive port) separately. A rate change on one port does not affect the others. If you set this field to Linear, the binary search algorithm searches all port pairs together, as a group. A rate change applies to all port pairs. Calibrate Latency If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. LDP Parameters No. of VCs Number of Virtual Circuits to establish with the DUT. The DUT must be configured to establish the same number of VCs as the Ixia port. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID. IP address used to establish LDP session with DUT. Internal loopback address on simulated CE router. The DUT must be configured to use this address as a tunnel endpoint.
No. of Trials
Binary Search
First VC ID
12-24

Table 12-11. Layer 2 VPN LDP Ingress Performance Test Parameters (Continued) Parameter L2 Interface Type Description Layer 2 interface to DUT. The setting of this parameter determines the type of validation traffic sent to the DUT. VLAN: If you set this parameter to VLAN, the test transmits VLAN-tagged traffic. Ethernet: If you set this parameter to Ethernet, the test transmits standard Ethernet frames. First VLAN ID Value of the first VLAN tag applied to VLAN-tagged traffic (if L2 Interface Type = VLAN). The DUT must be configured to be on the same VLAN. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. The first label in the range of MPLS labels.
Max Wait Time
MTU Size
Area ID
L2 VPN Parameters
12-25
12

Table 12-12. L2 VPN Settings Parameter Loss Tolerance Description The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Max Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The initial rate at which the test transmits frames. Enter this value as a number of frames per second. Select the number and type of VLAN tags added to the traffic: VLAN Based: Frames include only a single 802.1Q VLAN tag. QinQ: Frames include an 802.1Q tag and a second VLAN tag added as a service delimiter. Ethernet: Frames are raw Ethernet frames. Number of PEs per Port Enable Egress Burst Traffic Number of PE routers simulated on each port. If you check this box, the test bursts traffic on the egress ports.
Pass/Fail Criteria

Table 12-13. Layer 2 VPN LDP Ingress Performance Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
12-26

Table 12-13. Layer 2 VPN LDP Ingress Performance Test - Pass/Fail Criteria (Continued) Parameter Load Rate Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified. Data Errors The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors is less than or equal to the value you entered. Fail: The number of frames received with errors is greater than the number you entered.
12-27
12

LDP Partially-Meshed Performance Test
Test Results
Table 12-14 describes the LDP Ingress Performance test results.

Table 12-14. Layer 2 LDP Ingress Performance Test Results Result TxTput %TxTput DataErrors AvgLatency Low High SmallSeqError Description Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum. Number of frames received with errors Average latency, in nanoseconds Number of frames with latencies below the average Number of frames with latencies above the average Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.

12-28

Overview
This test determines the frame loss per VC for a label-switching router (LSR) configured as a Layer 2 VPN provider edge (PE) node. The DUT can be tested as either an ingress or egress node: If the DUT is an ingress node, it must apply or 'push' MPLS labels onto incoming Layer 2 packets and forward the resulting MPLS traffic at the specified transmit rate. If the DUT is an egress node, it must strip or pop the label from incoming MPLS packets and forward the resulting layer 2 traffic at the specified transmit rate.
This test requires at least two Ixia ports: one to simulate a PE router and another to simulate a customer edge (CE) router. You can use additional ports to simulate additional PE and CE routers, but the number of simulated PEs must equal the number of simulated CEs. The CE ports have a Layer 2 VLAN interface to the DUT.
1.1.1 VLANs 800 - 899 1.1.2 VLANs 900 - 999 DUT 1.1.3 VLANs 1000 - 1099 VCs 800 - 899 (Consecutive) VCs 602, 605, 608 (Round-robin) VCs 700 - 799 (Consecutive) VCs 601, 604, 607 (Round-robin) 1.2.3 VCs 600 - 699 (Consecutive) VCs 600, 603, 606 (Round-robin) 1.2.2 1.2.1
Configuration: CE ports: 1.1.1, 1.1.2, 1.1.3 PE ports: 1.2.1, 1.2.2, 1.2.3 First VC ID: 600 First VLAN ID: 800 No. VCs per PE: 100
Figure 12-8. LDP Partially-Meshed Performance Test
If you use more than two ports, the test maps VLAN IDs to VCs based on the order in which you add CE and PE ports to the map. For example, consider the following configuration:
Ports 1.1.1, 1.1.2, 1.1.3, 1.1.4
No. VCs per PE 100 First VLAN ID First VC ID 800 600
If you select 1.1.1 as a CE port and 1.1.2 as a PE port and add them to the map, then select 1.1.3 as a CE and 1.1.4 as a PE, the resulting port lists are:
12-29
12

CE 1.1.1 1.1.3
PE 1.1.2 1.1.4
If you select Consecutive VC distribution, the test allocates VCs and VLAN IDs as follows:
CE VLANs PE VCs
1.1.1 1.1.3
800-899 900-999
1.1.2 1.1.4
600-699 700-799
In a Consecutive VC distribution, the frames the DUT receives on one CE-connected port are forwarded out one PE-connected port.
Consecutive VC Distribution Configuration: ---------------------------------------CE ports: 1.1.1, 1.1.2, 1.1.3 PE ports: 1.2.1, 1.2.2, 1.2.3 First VC ID: 600 First VLAN ID: 800 No. VCs per PE: 100 PE Port List port 1 port 2 port 3 port 4 Increasing VC IDs
1.1.1 VLANs 800-899 1.1.2 VLANs 900-999 VCs 700-799 DUT 1.1.3 VLANs 1000-1001 VCs 800-899 VCs 600-699
1.2.1
1.2.2
1.2.3
Figure 12-9. Consecutive VC Distribution
If you select Round-robin VC distribution, the test allocates VCs and VLAN IDs as follows:
12-30

CE
VLANs
PE
VCs
1.1.1 1.1.3
800-899 900-999
1.1.2 1.1.4
600, 602, 700, 702, 601, 603, 701, 703,
In a Round-robin VC distribution, the frames that the DUT receives on one CEconnected port are forwarded out all its PE-connected ports.
Configuration: ------------------------------------------CE ports: 1.1.1, 1.1.2, 1.1.3 PE ports: 1.2.1, 1.2.2, 1.2.3 First VC ID: First VLAN ID: No. VCs per PE: 600 800 100 PE Port List
Round-robin VC Distribution port 1 port 2 port 3 port 4 Increasing VC IDs
1.1.1 VLANs 800-899 1.1.2 VLANs 900-999 VCs 601 . . . 701 . . . 801 . . . DUT 1.1.3 VLANs 1000-1001 VCs 602 . . . 702 . . . 802 . . . VCs 600 . . . 700 . . . 800 . . .
1.2.1
1.2.2
1.2.3
Figure 12-10.Round-robin VC Distribution
The test maps VLAN IDs to VCs consecutively:

VLAN ID 800 801 802 803 8xx 900 901 VC 600 601 602 603 6xx 700 701
12-31
12

9xx 1000 1001 1xxx
7xx 800 801 8xx
12-32

The configuration phase of this test proceeds as follows: The port simulating the PE router establishes an OSPF session and advertises a Router Link State Advertisement (RLSA) for a simulated network Provider (P) router. The RLSA includes the loopback address of the simulated PE router. An LDP session then advertises a Forwarding Equivalence Class (FEC) for the simulated PE router. The tunnel label value is configurable. However, if the DUT encapsulates control traffic with an MPLS label, you must set the Label value to 3 (an implicit null label). Otherwise, the Ixia port interprets the control traffic as data traffic and does not process the packet correctly. A Martini session is established with the DUT.
No protocols are established on the port simulating the CE router because this port's only function is to generate layer 2 traffic to the VCs advertised by the simulated PE router. For the load testing phase of the test, both CE and PE ports transmit traffic at the specified rate. For each trial, the results show: Frame loss per VC ID Lowest, highest, and average latencies Data errors Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 12-15 on page 12-33.
12-33
12

Table 12-15. Layer 2 VPN LDP Partially-Meshed Performance Test Parameters Parameter Duration Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. Transmit direction. You can select from the following directions: Bidirectional: Each port transmits to every other port. This option tests the DUTs ability to strip or pop MPLS labels from packets going to the CE and while simultaneously applying or pushing MPLS labels packets going to the PE. PE->CE: PE ports transmit to only to CE ports. This option tests the DUTs ability to strip or pop MPLS labels and forward them to the CE. CE->PE: CE ports transmit to only to PE ports. This option tests the DUTs ability to apply or push MPLS labels onto IP packets and forward the resulting MPLS traffic to the PE. No. of Trials The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. Pause Before Transmit Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration.
Tx Direction
Calibrate Latency
LDP Parameters No. of VCs per PE Number of Virtual Circuits each PE is to establish with the DUT. The DUT must be configured to establish the same number of VCs. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID. IP address used to establish LDP session with DUT. Internal loopback address on simulated CE router. The DUT must be configured to use this address as a tunnel endpoint.
First VC ID
First PE Loopback IP Peer IP Address
12-34

Table 12-15. Layer 2 VPN LDP Partially-Meshed Performance Test Parameters (Continued) Parameter VC ID Distribution Description Method used to distribute VC IDs among two or more ports simulating PE routers. If you select Consecutive, the test distributes ranges of consecutive VC IDs to the PE ports, in the order the ports are listed in the PE port list. If you select Round-robin, the test distributes VC IDs one at a time, cycling through the ports in the order they are listed in the PE port list. First VLAN ID Value of the first VLAN tag applied to VLAN-tagged traffic (if L2 Interface Type = VLAN). The DUT must be configured to be on the same VLAN. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. Layer 2 interface to DUT. The setting of this parameter determines the type of validation traffic sent to the DUT. VLAN: If you set this parameter to VLAN, the test transmits VLAN-tagged traffic. Ethernet: If you set this parameter to Ethernet, the test transmits standard Ethernet frames. Label Start Value IGP Parameters Interface Network Type OSPF interface network type. If you are using a POS load module, select Point-to-point. If you are using an Ethernet load module, select Broadcast. OSPF area of the simulated CE router The first label in the range of MPLS labels.
Max Wait Time
MTU Size
L2 Interface Type
Area ID Advanced Parameters Start Reserved VLAN ID
First VLAN ID in reserved range. Some devices reserve a range of VLAN IDs for their own internal use. You can use the Start and End Reserved VLAN ID parameters to define this range. When you run the test, it skips the reserved VLAN IDs when it transmits. Last VLAN ID in reserved range.
MAC Learn Frame Parameters
12-35
12

Table 12-15. Layer 2 VPN LDP Partially-Meshed Performance Test Parameters (Continued) Parameter Frequency Description Determines when the test sends the MAC Learn frames. On Trial: The test sends MAC Learn frames before the start of each trial. Never: The test never sends MAC Learn frames. No. of Frames to Each Host Rate Number of MAC Learn frames sent to each host. Rate at which the test sends MAC Learn frames.
L2 VPN Parameters
Table 12-16. L2 VPN Settings Parameter Loss Tolerance Description The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Max Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The initial rate at which the test transmits frames. Enter this value as a number of frames per second. Select the number and type of VLAN tags added to the traffic: VLAN Based: Frames include only a single 802.1Q VLAN tag. QinQ: Frames include an 802.1Q tag and a second VLAN tag added as a service delimiter. Ethernet: Frames are raw Ethernet frames. Number of PEs per Port Enable Egress Burst Traffic Number of PE routers simulated on each port. If you check this box, the test bursts traffic on the egress ports.
Pass/Fail Criteria
12-36

Table 12-17. Layer 2 VPN LDP Partially-Meshed Performance Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified. Data Errors The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors is less than or equal to the value you entered. Fail: The number of frames received with errors is greater than the number you entered. % Frame Loss Percentage of frames transmitted that were lost by the DUT. You can select either of two methods to calculate the percentage of frames lost: Average/Port: The test averages the frame loss over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Latency
12-37
12

Martini Sessions Scalability Test
Test Results
Table 12-18 describes the LDP Partially-Meshed Performance test results.

Table 12-18. Layer 2 LDP Partially-Meshed Performance Test Results Result TxTput %TxTput DataErrors AvgLatency Low High Description Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum. Number of frames received with errors Average latency, in nanoseconds Number of frames with latencies below the average Number of frames with latencies above the average

Overview
This test determines the maximum number of Martini sessions over which a label-switching router (LSR) can forward VPN traffic with no loss. The LSR must create enough VRF tables to support the number of simulated VPNs, establish the required number of Martini sessions, apply labels to the incoming traffic, and then forward the incoming traffic to the correct VPN. This test requires a minimum of two ports, using a one-to-many port mapping. One port simulates a Provider Edge (PE), a Provider core (P), and one or more Customer Edge (CE) routers that are the destination of the incoming traffic. The other port simulate(s) the Customer Edge routers that belong to the same VPNs as the destination CE routers, and are the origin of the test traffic. The configuration phase of this test proceeds as follows: 1. The port simulating the PE router establishes an OSPF session and advertises a Router Link State Advertisement (RLSA) for the simulated P router. The RLSA includes the loopback address of the simulated PE router. 2. An LDP session advertises a Forwarding Equivalence Class (FEC) for the simulated PE router. 3. If the DUT encapsulates control traffic with an MPLS label, you must set its LDP Label value to 3 (a null label). Otherwise, the Ixia port interprets the control traffic as data traffic and does not process the packet correctly.
12-38

4. For each simulated destination CE router (VPN), one Martini session is established with the DUT. No protocols are established on the port simulating the originating CE routers because this port's role is simply to generate Layer 2 or VPN traffic to the VCs advertised from the simulated PE node. The port simulating the CE origin transmits unidirectional traffic at the specified rate. The quantity and type of generated traffic are configurable. The type of traffic generated depends on the setting for the L2 Interface Type parameter. If the interface to the PE node is a standard Layer 2 interface (L2 Interface Type = Ethernet), the test generates ordinary Ethernet traffic. If the interface to the PE node is a VLAN interface (L2 Interface Type = VLAN), the test generates VLAN-tagged traffic. After allowing the DUT time to apply labels and forward the frames (controlled by the Pause Before Tx parameter), the test increases the number of VCs and VPNs and transmits the same number of frames again to each VC/VPN. The test continues until the frame loss exceeds the Loss Tolerance. It then reports the last successful number of VCs and VPNs. For each trial, the test results show: the number of frames transmitted the number of frames received the percentage of lost frames the maximum number of VCs and VPNs the DUT can sustain
12-39
12

Layer 2 VPN traffic

VPN 1 VC 4 VPN 2 VC 5 VPN 3 VC 6
Martini-labeled traffic Martini sessions
Layer 2 VPN traffic

VPN 1 VC 4 VPN 2 VC 5
DUT DUT Provider Edge Provider (P) router LSP tunnels Provider Edge routers
VPN 3 VC 6
VPN x VC n
VPN x VC n
Customer Edge routers Simulated Customer Edge routers

VPN 1 VC 4
Customer Edge routers
Layer 2 VPN traffic
VPN x VC n
VPN 1 VC 4
DUT Martinilabeled traffic Simulated Provider (P) router LSP tunnels
VPN x VC n
Simulated Customer Edge routers
Simulated Provider Edge routers
Martini sessions
Figure 12-11. Layer 2 VPN Martini Sessions Scalability Test Scenario
Table 12-19. Layer 2 VPN Martini Sessions Scalability test parameters Parameter No. of Trials Description The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results.
No. of Frames per VPN Number of validation frames sent to each VPN. Max Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate.
12-40

Table 12-19. Layer 2 VPN Martini Sessions Scalability test parameters (Continued) Parameter Loss Tolerance Description The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Pause Before Transmit Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration.
LDP Parameters Initial #VPNs Increment by: Max VPNs Initial number of VPNs advertised to the DUT. Number of additional VPNs advertised for each iteration. Maximum number of VPNs that are to be advertised to the DUT. The DUT must be configured to accommodate this number of VPNs. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID. Number of additional VCs established for each iteration. IP address used to establish LDP session with DUT. Octet in PE Loopback IP address to be incremented in order to create new LSPs. The DUT must be configured to create LSPs using each incremented PE Loopback IP address. Amount to increment PE Loopback IP address for each iteration. Internal loopback address on simulated CE router. The DUT must be configured to use this address as a tunnel endpoint. Layer 2 interface to DUT. The setting of this parameter determines the type of validation traffic sent to the DUT. VLAN: If you set this parameter to VLAN, the test transmits VLAN-tagged traffic. Ethernet: If you set this parameter to Ethernet, the test transmits standard Ethernet frames. First VLAN ID Value of the first VLAN tag applied to VLAN-tagged traffic (if L2 Interface Type = VLAN). The DUT must be configured to be on the same VLAN.
First VC ID
Increment by: PE Loopback IP Octet to Increment
Increment by: Peer IP Address
L2 Interface Type
12-41
12

Table 12-19. Layer 2 VPN Martini Sessions Scalability test parameters (Continued) Parameter MTU Size Description Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. The first label in the range of MPLS labels.
Max Wait Time
Area ID
Pass/Fail Criteria

Table 12-20. Layer 2 VPN Martini Sessions Scalability Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of Martini sessions established with the DUT. Pass: The number of Martini sessions established with the DUT is equal to or greater than the number you entered. Fail: The number of Martini Sessions established with the DUT is lower than the number you entered.
No of Martini Sessions
12-42

Test Results
Table 12-21 describes the Martini Sessions Scalability test results.

Table 12-21. Layer 2 VPN Martini Sessions Scalability Test Results Result TxTput %TxTput DataErrors AvgLatency Low High SmallSeqError Description Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum. Number of frames received with errors Average latency, in nanoseconds Number of frames with latencies below the average Number of frames with latencies above the average Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.
12-43
12

Virtual Circuits Scalability Test

Overview
This test determines the maximum number of Virtual Circuits (VCs) a labelswitching router (LSR) can support over a single Martini session with no loss. The LSR must apply labels to incoming traffic and forward the traffic over the correct VC to its destination. This test requires two ports minimum, using a one-to-one port mapping. One port simulates a Provider core (P) router, a Provider Edge (PE) router, and one or more Customer Edge (CE) routers that are the destination of the test traffic. The other port simulates the Customer Edge routers that belong to the same VPNs as the destination CE routers, and are the origin of the test traffic. The configuration phase of this test proceeds as follows: 1. The port simulating the PE router establishes an OSPF session and advertises a Router Link State Advertisement (RLSA) for a simulated Provider (P) router. The RLSA includes the loopback address of the simulated PE router. 2. An LDP session advertises a Forwarding Equivalence Class (FEC) for the simulated PE router. 3. If the DUT encapsulates control traffic with an MPLS label, you must set the Label value to 3 (a null label). Otherwise, the Ixia port interprets the control traffic as data traffic and does not process the packet correctly. 4. A Martini session is established with the DUT. No protocols are established on the port simulating the origin CE routers because this port's role is simply to generate layer 2 traffic to the VCs advertised from the simulated PE node. The port simulating the origin CE routers transmits unidirectional traffic at the specified rate. The quantity and type of generated traffic are configurable. The type of traffic generated depends on the setting for the L2 Interface Type parameter. If the interface to the PE node is a standard Layer 2 interface (L2 Interface Type = Ethernet), the test generates ordinary Ethernet traffic. If the interface to the PE node is a VLAN interface (L2 Interface Type = VLAN), the test generates VLAN-tagged traffic. After allowing the DUT time to apply labels and forward the frames (controlled by the Pause Before Tx parameter), the test increases the number of VCs and transmits the same number of frames again to each VC. The test continues until
12-44

the frame loss exceeds the Loss Tolerance. It then reports the last successful number of VCs. For each trial, the test results show: the number of frames transmitted the number of frames received the frame loss percentage the maximum number of VCs the DUT could sustain
Layer 2 VPN traffic

VC 4
Labeled traffic Martini session
Layer 2 VPN traffic

VC 4
VC 5
VC 5
DUT DUT Provider Edge LDP session
VC 6
Provider Core LSP tunnels
Provider Edge
VC 6
VC n
VC n
Customer Edge routers Simulated Customer Edge routers

VC 4
Customer Edge routers
Layer 2 VPN traffic
VC n
DUT
VC 4
LDP session Simulated Provider Core router
LSP tunnels
VC n
Simulated Customer Edge routers
Simulated Provider Edge router
Labeled traffic
Martini session
Figure 12-12.Layer 2 VPN VC Scalability Test Scenario
Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 12-22 on page 12-45.
12-45
12

Note: When you configure the parameters for the VC Scalability test, you must specify initial values that allow the test to complete at least one iteration without frame loss. The test works by increasing the load on the DUT with each successive iteration until frame loss occurs, and then it stops and reports the results. If frame loss occurs on the first iteration, the test does not report any results.
Table 12-22. Layer 2 VPN VC Scalability Test Parameters Parameter No. of Trials Description The number of trials to be run. It may be necessary to run several trials of the test to verify for consistent results. Number of validation frames sent over each VC. The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Pause Before Transmit Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration.
No. of Frames per VC Max Rate
Loss Tolerance
LDP Parameters No. of VCs Increment by: First VC ID Initial number of VCs established with DUT. Number of additional VCs established for each iteration. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID. IP address used to establish LDP session with DUT. Internal loopback address on simulated CE router. The DUT must be configured to use this address as a tunnel endpoint. Layer 2 interface to DUT. The setting of this parameter determines the type of validation traffic sent to the DUT. VLAN: If you set this parameter to VLAN, the test transmits VLAN-tagged traffic. Ethernet: If you set this parameter to Ethernet, the test transmits standard Ethernet frames.
L2 Interface Type
12-46

Table 12-22. Layer 2 VPN VC Scalability Test Parameters (Continued) Parameter First VLAN ID Description Value of the first VLAN tag applied to VLAN-tagged traffic (if L2 Interface Type = VLAN). The DUT must be configured to be on the same VLAN. Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. The first label in the range of MPLS labels.
MTU Size
Max Wait Time
Area ID
Pass/Fail Criteria

Table 12-23. Layer 2 VPN VC Scalability Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of Virtual Circuits (VCs) established with the DUT. Pass: The number of VCs established with the DUT is equal to or greater than the number you entered. Fail: The number of VCs established with the DUT is lower than the number you entered.
No of VCs
Test Results
Table 12-24 describes the Martini Sessions Scalability test results.

Table 12-24. Layer 2 VPN VC Scalability Test Parameters Result TxTput %TxTput DataErrors AvgLatency Description Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum. Number of frames received with errors Average latency, in nanoseconds
12-47
12

Table 12-24. Layer 2 VPN VC Scalability Test Parameters (Continued) Result Low High SmallSeqError Description Number of frames with latencies below the average Number of frames with latencies above the average Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.
12-48
13
Chapter 13:
This chapter covers the following topics: Overview of the Layer 3 VPN Test Suite on page 13-1. DUT Setup on page 13-2.
Performance and Scalability Test on page 13-7 determines the no-drop
throughput between VPN sites.

A Layer 3 VPN is a VPN architecture that uses BGP to distribute VPN routing information across the provider backbone, and MPLS to forward the VPN traffic across the backbone to remote VPN sites. Layer 3 VPNs are also known as BGP/ MPLS VPNs or RFC 2547bis VPNs. RFC 2547bis defines a mechanism that enables service providers to provide VPN services to their customers over the providers' existing backbones. RFC 2547bis VPNs function like private IP networks. To differentiate the VPNs from each other, a VPN identifier is prefixed to each address from a particular VPN site, creating an address that is unique both inside and outside the VPN. In an RFC 2547bis VPN, the CE (Customer Edge) and Provider Edge (PE) routers are peers of each other. The CE router provides the PE router with the routing information for its private network. The PE router stores this private routing information in a table called a VPN routing and forwarding (VRF) table. The PE router maintains a separate VRF table for each VPN connected to a CE router. Users within a VPN are only permitted to access other sites or hosts within the same VPN. In addition to the VRF tables, the PE router also stores the normal routing information it needs to send traffic over the public Internet.
13-1
13

DUT Setup
Edge router, Customer A VPN CE Service provider edge router PE VPN CE Edge router, Customer B
----VRF table Customer A ----VRF table Customer B ----Internet Routing Table -----
LSP
Service provider router P
Figure 13-1. Layer 3 (RFC 2547bis) VPN Components
At the center of a Layer 3 VPN network, MPLS forwards traffic across the core routers to the destination PE router. Using MPLS relieves the provider core (P) routers from needing to maintain forwarding information beyond the edge of the network. A RFC 2547bis network uses a two-level label stack. When a packet arrives on an ingress PE router, it pushes onto the packet a Next-Hop BGP header that contains information about the destination private network. The second (outer) label is a Next-Hop Interior Gateway Protocol (IGP) header that contains forwarding information used to move the packet across the shared public infrastructure. After the packet has traversed the network across one or more MPLS Label Switched Paths (LSPs), and reached the egress PE router, the PE pops the MPLS headers and delivers a normal IP packet to the CE router.
DUT Setup
Table 13-1 contains an example of how to configure a Cisco router as the DUT for the Layer 3 VPN Ingress and Egress Performance tests. Table 13-2 on page 13-4 describes a configuration for Layer 3 VPN RSVP-TE tests. Table 13-3 on page 13-6 describes a configuration for the Layer 3 Performance and Scalability test. Use these examples as guides to configuring your own DUT.
13-2

DUT Setup
Sample Cisco DUT configuration for Layer 3 VPN Ingress and Egress Tests Description Enables Cisco Express Forwarding (CEF) Enables LDP on the router VRF configuration
Router(config)# ip cef distributed Router(config)# mpls label protocol ldp Router(config)# ip vrf VPN1 Router(config)# route-target both 1:1 Router(config)# rd 1:1 Router(config)# interface loopback 0 Router(config-if)# ip address 11.11.11.11 255.255.255.255 Router(config-if)# exit Router(config)# router ospf 10 Router(config-router)# network 10.0.1.0 0.0.0.255 area 0 Router(config-if)# exit Router(config)# interface fastEthernet 0/0/1 Router(config-if)# ip address 10.0.1.1 255.255.255.0 Router(config-if)# ip ospf network broadcast Router(config-if)# mpls ip Router(config-if)# mpls label protocol ldp Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface fastEthernet 0/0/2 Router(config-if)# ip vrf forwarding VPN41 Router(config-if)# ip address 11.0.1.1 255.255.255.0 Router(config-if)# ip ospf network broadcast Router(config-if)# mpls label protocol ldp Router(config-if)# mpls ip Router(config-if)# no shutdown Router(config-if)# exit Router(config)# router ospf 11 vrf VPN1 Router(config-router)# network 11.0.1.0 0.0.0.255 area 0
Internal loopback configuration
OSPF configuration
PE (Provider Edge) port configuration
CE (Customer Edge) port configuration
PE-CE routing (OSPF)
13-3
13

DUT Setup
Sample Cisco DUT configuration for Layer 3 VPN Ingress and Egress Tests (Continued) Description BGP configuration
Router(config)# router bgp 1 Router(config-router)# no bgp default ipv4-unicast Router(config-router)# neighbor 11.11.11.2 remote-as 1 Router(config-router)# neighbor 11.11.11.2 updatesource loopback 0 Router(config-router)# neighbor 11.11.11.2 activate Router(config-router-af)# address-family vpnv4 Router(config-router-af)# neighbor 11.11.11.2 activate Router(config-router-af)# exit Router(config-router)# exit Router(config)# router bgp 1 Router(config-router)# address-family ipv4 vrf VPN1 Router(config-router-af)# redistribute ospf 11 outer(config-router-af)# exit Router(config-router)# exit Router(config)# exit
Redistributes CE OSPF route to BGP
Sample Cisco DUT configuration for Layer 3 VPN RSVP-TE Tests Description Enables Cisco Express Forwarding (CEF) Enables LDP on the router VRF configuration
Router(config)# ip cef distributed Router(config)# mpls ip Router(config)# ip vrf VPN1 Router(config)# route-target both 1:1 Router(config)# rd 1:1 Router(config)# interface loopback 0 Router(config-if)# ip address 11.11.11.11 255.255.255.255 Router(config-if)# exit Router(config)# router ospf 10 Router(config-router)# network 10.0.1.0 0.0.0.255 area 0 Router(config-router)# mpls traffic-eng router-id Loopback0 Router(config-router)# mpls traffic-eng area 0 Router(config-if)# exit
Internal loopback configuration
OSPF Configuration
13-4

DUT Setup
Sample Cisco DUT configuration for Layer 3 VPN RSVP-TE Tests (Continued) Description Tunnel configuration
Router(config)# interface Tunnel1 Router(config-if)# ip unnumbered Loopback0 Router(config-if)# tunnel destination 11.11.11.2 Router(config-if)# tunnel mode mpls traffic-eng Router(config-if)# tunnel mpls traffic-eng autoroute announce Router(config-if)# tunnel mpls traffic-eng priority 7 7 Router(config-if)# tunnel mpls traffic-eng bandwidth 1000 Router(config-if)# tunnel mpls traffic-eng pathoption 2 dynamic Router(config-if)# ip rsvp bandwidth 10 10 Router(config-if)# mpls ip Router(config-if)# exit Router(config)# interface fastEthernet 0/0/1 Router(config-if)# ip address 10.0.1.1 255.255.255.0 Router(config-if)# ip ospf network broadcast Router(config-if)# mpls ip Router(config-if)# mpls traffic-eng tunnels Router(config-if)# ip rsvp bandwidth 10000 10000 Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface fastEthernet 0/0/2 Router(config-if)# ip vrf forwarding VPN1 Router(config-if)# ip address 11.0.1.1 255.255.255.0 Router(config-if)# ip ospf network broadcast Router(config-if)# mpls ip Router(config-if)# no shutdown Router(config-if)# exit Router(config)# router ospf 11 vrf VPN1 Router(config-router)# network 11.0.1.0 0.0.0.255 area 0
Provider Edge (PE) port config
Customer Edge (CE) port configuration
PE-CE routing (OSPF)
13-5
13

DUT Setup
Sample Cisco DUT configuration for Layer 3 VPN RSVP-TE Tests (Continued) Description BGP configuration
Router(config)# router bgp 1 Router(config-router)# no bgp default ipv4-unicast Router(config-router)# neighbor 11.11.11.2 remote-as 1 Router(config-router)# neighbor 11.11.11.2 updatesource loopback 0 Router(config-router)# neighbor 11.11.11.2 activate Router(config-router-af)# address-family vpnv4 Router(config-router-af)# neighbor 11.11.11.2 activate Router(config-router-af)# exit Router(config-router)# exit Router(config)# router bgp 1 Router(config-router)# address-family ipv4 vrf VPN1 Router(config-router-af)# redistribute ospf 11 Router(config-router-af)# exit Router(config-router)# exit Router(config)# exit Table 13-3. Command conf t ip vrf VPN1 rd 1:1 route-target both 1:1 conf t interface Loopback0 ip address 1.2.3.4 255.255.255.255 interface FastEthernet4/0/1 ip address 42.1.1.1 255.255.255.0 ip ospf network broadcast full-duplex mpls label protocol ldp mpls ldp discovery transport-address interface mpls ip conf t router ospf 42 network 42.1.1.0 0.0.0.255 area 0 conf t router bgp 1 no bgp default ipv4-unicast neighbor 11.11.11.2 remote-as 1 neighbor 11.11.11.2 update-source loopback 0 neighbor 11.11.11.2 activate address-family vpnv4 neighbor 11.11.11.2 activate
Redistributes CE OSPF route to BGP
Sample Cisco DUT configuration for Layer 3 Performance and Scalability Test Description VRF configuration
Configure the loopback address
Configure the PE port
Configure OSPF
Configure BGP-VPN
13-6

Performance and Scalability Test
Table 13-3. Command
Sample Cisco DUT configuration for Layer 3 Performance and Scalability Test (Continued) Description Configure the CE interface
ip vrf forwarding VPN1 ip address 61.1.1.1 255.255.255.0 ip ospf network broadcast mpls label protocol ldp mpls ip router ospf 61 vrf VPN1 network 61.1.1.0 0.0.0.255 area 0 router bgp 1 address-family ipv4 vrf VPN1 redistribute ospf 61 router rip version 2 address-family ipv4 vrf VPN1 version 2 redistribute bgp 1 metric 0 network 150.150.0.0 no auto-summary exit-address-family router bgp 1 address-family ipv4 vrf vrf1 redistribute rip no auto-summary no synchronization exit-address-family
Configure OSPF for the PE-CE link (61 is CE router OSPF process) (CE interface address is 61.1.1.1/24) Redistribute CE OSPF routes in VPN1 Configure RIP for the PE-CE link (Not required if PE-CE protocol is OSPF)
Redistribute BGP routes to RIP
Rip routes to be redistributed to BGP

This section covers the following topics: Overview on page 13-7. Test Cycle on page 13-8. Configuring the Test Parameters on page 13-9. Pass/Fail Criteria on page 13-15. Test Results on page 13-16. Configuration Examples on page 13-16.
Overview
The Layer 3 Performance and Scalability test emulates a VPN topology surrounding a PE router (the DUT). The Ixia ports connected to the DUT emulate local and remote VPN sites. Each emulated site can advertise multiple VPN routes.
13-7
13

To determine the DUTs ability to retain the routes and forward traffic to the VPNs, the test sends IP traffic to the VPN sites. The test uses a binary search algorithm to determine the highest rate at which the DUT can transmit traffic to the emulated VPN sites with no packet loss.
Note: This test is supported on the LM1000TXS4 or LM100TXS8 family of load modules. This includes LM1000SFP4, LM1000SFPS4, LM1000SFPS4-256, LM1000STXS4, LM1000STXS4-256, LM1000TXS4, LM1000TXS4-256, LM100TXS8, OLM1000STX24, and OLM1000STXS24. The test is supported also on the LM10GULF-P and LM10GE700F1P load modules.
Routes Customer Edge (CE) DUT Provider Edge (PE) Routes Customer Edge (CE) Provider (P) Provider Edge (PE) Routes VRF Routes VRF
Provider Edge (PE) Ixia CE port Ixia P/PE port
Figure 13-2. Layer 3 Performance and Scalability Test Scenario
The DUT is configured as a PE device. One group of Ixia ports simulate one Provider (P) and multiple Provider Edge (PE) routers on one side of the DUT. The P and PE routers advertise routes to VPN sites. The other Ixia ports simulate Customer Edge (CE) routers emulate the local VPN sites directly connecting with DUT. The test creates the same number of VPN sites on the CE side as on the PE side. If you assign more than one port to the PE and CE sides, the test distributes the VPN sites and routes evenly among all the ports; the PE-side VPN sites and routes are evenly distributed across all PE ports; the CE-side VPN sites and routes are evenly distributed across all CE ports.
Test Cycle
The test begins by configuring ARP and the IP addresses it is to use. If VLANs are enabled, the test also configures VLAN IDs on the CE ports. On the PE ports, the test configures the routing protocol, the label protocol, and finally, configuring the VRFs on the BGP neighbors. The test then configures the selected CE-PE protocol. Next, the test starts the configured protocols on the CE and PE ports and sends ARP frames. It confirms that the sessions are up, and then collects the received MPLS and VPN route labels. The test configures streams of IP traffic (including VLAN headers, if enabled) on on the CE ports and MPLS traffic on the PE ports. It waits for the Delay time to
13-8

expire and then begins transmitting traffic to every address in every VPN. If the DUT loses any frames, the test reduces the transmit rate and transmits again. When the test transmits at a reduced rate and the DUT loses no frames, the test performs a binary search to find the precise rate at which the DUT loses no frames. Any ports with no frame loss are excluded from the binary search. The test repeats this process for each frame size. After finding the no-loss transmit rate, the test transmits again at the no-loss rate and then checks the received frames for sequence errors. At the end of the test, the test calculates and displays the results. There are two result files: a per-port summary that also includes the sequence error r check, and a file that shows the results on a per-VRF basis.
Layer 3 Performance and Scalability Test Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. Amount of time the test waits before transmitting the test traffic. The delay allows the DUT time to absorb the advertised routes and update its routing tables. The test also observes the delay before it collects the RSVP labels. If your test topology is large and includes a large number of VRFs or routes, you may need to increase the delay.
No. of Trials
Max Rate
Delay
13-9
13

Table 13-4. Parameter Direction
Layer 3 Performance and Scalability Test Parameters (Continued) Description Transmit direction. You can select from the following directions: Bidirectional: Each port transmits to every other port. This option tests the DUTs ability to route VPN traffic in both directions simultaneously. PE->CE: PE ports transmit only to CE ports. This option tests the DUTs ability to route VPN traffic in the PE-to-CE direction. CE->PE: CE ports transmit only to PE ports. This option tests the DUTs ability to route VPN traffic in the CE-to-PE direction.
Binary Search
Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the algorithm searches each port pair separately. A rate change on one port does not affect the others. If you set this field to Linear, the algorithm searches all port pairs together, as a group. A rate change applies to all port pairs.
Staggered Transmit
If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously.
Calibrate Latency
Protocol Parameters IGP Protocol Interface Network Type Inter-gateway protocol used on the networks simulated by the Ixia ports. Select OSPF or IS-IS. OSPF network type. If you are using a POS load module, select Point-to-point. If you are using an Ethernet load module, select Broadcast. Label-switching protocol used on the networks simulated by the Ixia ports to route traffic between the DUT and the Ixia ports. Select LDP or RSVP-TE.
MPLS Protocol
PE Parameters Number of PE Routers per P Port Number of PE routers simulated on each port simulating the service provider (P) network.
13-10

Table 13-4. Parameter BGP AS
Layer 3 Performance and Scalability Test Parameters (Continued) Description The Autonomous System number associated with the simulated PE routers. IP address used to establish LDP peering session. Specify this address as an IPv4 address followed by / # to indicate the subnet mask. For example: 11.13.15.3/24. If you do not specify a subnet mask, the test assumes a 32-bit mask. Increment by: Octet to increment the Emulated PE Loopback IP Address to create additional addresses, and amount of increase between each address. For example, if you accept the default value of 0.0.0.1, the test increments the fourth octet of the Emulated PE Loopback IP Address by 1 to create each new address. If the test increments the octet to 254 and still needs to create additional addresses, it begins incrementing the next most-significant octet.
Emulated PE Loopback IP Address
DUT Loopback IP Address
Internal loopback address on simulated PE router. Tunnels use this address as an endpoint. Specify this address as an IPv4 address followed by / # to indicate the subnet mask. For example: 11.13.15.3/24. If you do not specify a subnet mask, the test assumes a 32-bit mask. Increment by: Octet to increment the DUT Loopback IP Address to create additional addresses, and amount of increase between each address. For example, if you accept the default value of 0.0.0.1, the test increments the fourth octet of the DUT Loopback IP Address by 1 to create each new address. If the test increments the octet to 254 and still needs to create additional addresses, it begins incrementing the next most-significant octet.
VRF Parameters Number of VRFs per PE Number of VPN Routing and Forwarding (VRF) tables simulated for each PE router. A VRF is a per-site or per-interface routing table. A VRF may be shared by several interfaces, since multiple corporate sites may connect to the same PE router.
13-11
13

Layer 3 Performance and Scalability Test Parameters (Continued) Description Determines the number of unique VRFs in the test. If you check this box, every VRF is different from every other VRF used in the test (Unique VRFs = No. of PE Routers x No. of VRFs per PE Router). The traffic pattern is peer-to-peer. If you do not check this box, every VRF is different from every other VRF on a PE router, but every PE router uses the same VRFs (Unique VRFs = No. of VRFs per PE Router). The traffic pattern is partiallymeshed, meaning that each CE port transmits to every PE port and each PE port transmits to every CE port. Note: If you want the test to check for sequence errors, you must enable unique VRFs.
Enable Unique VRF
Number of Routes per VRF First Route
Number of routes stored by each VRF. IP address of the first VPN stored in the first VRF on the first PE port. Prefix Length: Route address mask width Increment by: Octet to increment the First Route address to create additional routes, and amount of increase between each address. The test creates addresses for the PE ports first, then creates addresses for the CE ports. For example, if you accept the default value of 0.0.1.0, the test increments the third octet of the First Route address by 1 to create each new address. If the test increments the octet to 254 and still needs to create additional addresses, it begins incrementing the next most-significant octet.
13-12

Layer 3 Performance and Scalability Test Parameters (Continued) Description Number prefixed to IP addresses to distinguish between duplicate private addresses. The Route Distinguisher (RD) is made up of two parts, the Admin part and AS number. Note: This test supports an Admin part Type of Autonomous System only, meaning that the Administrator subfield is 2 bytes long and contains an Autonomous System number (ASN). Enter an RD as two numbers, separated by a colon: ASN: 2-byte Autonomous System Number to be placed in the Administrator subfield of the Value field of the RD. The ASN is the globally-significant part of the RD. Assigned Number: This is the Assigned Number subfield of the Value field of the VPN Route Distinguisher. This number is drawn from a numbering space administered by an enterprise for a given ASN space. The Assigned Number is the locally-significant part of the RD. For example, the default value pair, 1:1, represents an RD with AS = 1 and Assigned Number = 1. To create additional route distinguishers, the test increments both numbers simultaneously. For example, 1:1, 2:2, 3:3, and so on.
Route Distinguisher
VPN Label Start MPLS Label Start CE Parameters CE - PE Protocol ISIS Level
The first label to use in BGP MPLS packets. The first label in the range of MPLS labels.
Protocol used between simulated CE and PE routers. Select OSPF, IS-IS, EBGP, or RIP. If you set the CE - PE Protocol to IS-IS, select the type of IS-IS links to be created for the CE-PE connection: Level 1 Internal ISIS links within a single ISIS area are created. Level 2 External ISIS links between multiple ISIS areas are created. Level 1 + 2 Both types of ISIS links can be created.
BGP AS
If you set the CE - PE Protocol to EBGP, enter the BGP Autonomous System number assigned to the local BGP AS of the emulated CE router. If you set the CE - PE Protocol to OSPF, enter the OSPF Area ID of the emulated CE router.
OSPF Area ID
13-13
13

Layer 3 Performance and Scalability Test Parameters (Continued) Description If you check this box, the test creates a VLAN for each port that simulates a CE router and inserts VLAN tags into traffic from the ports. First VLAN ID assigned to the CE routers. If you assign more than one port to simulate CE routers, the test increments the VLAN ID to create a unique VLAN ID for each port.
Enable VLAN
First VLAN ID
Table 13-5 lists the combined maximum numbers of routes, simulated PE routers and VRFs that can be configured per port. Ensure that the values you enter for these parameters do not exceed the maximum for the port type you plan to use in the test.
Table 13-5. Maximum Number of Routes, PE Routers, and VRFs per Port Maximum Number of Routes, PE Routers, and VRFs per Port Unique VRFs: Number of Routes * Number of PE Routers * Number of VRFs < 24000 Non-Unique VRFs: Number of Routes * Number of PE Routers * Number of VRFs < 16000 LM100TXS8 Unique VRFs: Number of Routes * Number of PE Routers * Number of VRFs < 8000 Non-Unique VRFs Number of Routes * Number of PE Routers * Number of VRFs < 5333
Load Module Type LM1000TXS4
13-14

Pass/Fail Criteria

Table 13-6. Parameter Pass Criteria Layer 3 VPN Performance and Scalability Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency time experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
13-15
13

Layer 3 VPN Performance and Scalability Test - Pass/Fail Criteria (Continued) Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors is less than or equal to the value you entered. Fail: The number of frames received with errors is greater than the number you entered.
Test Results
Table 13-7 describes the Layer 3 Performance and Scalability test results.
Table 13-7. Result Total Frames Transmitted Total Frames Received Total Frames Expected to be Received Total Packet Loss (%) Throughput as a percentage of maximum frame rate Throughput in frames per second Average Latency (ns) Data Errors Layer 3 Performance and Scalability test results Description Total number of frames transmitted. Total number of frames received. Total number of frames that should have been received. Percentage of packets lost. Throughput expressed as a percentage of the maximum theoretical frame rate. Throughput expressed in terms of frames per second (f/s). Average latency, in nanoseconds. Number of packets received that contained errors.
Configuration Examples
This section shows how the L3 VPN Performance and Scalability test allocates addresses and how the addresses transmit to each other. Two examples are included: one that uses non-unique VRFs and one that uses unique VRFs. Figure 13-3 on page 13-17 shows the topology used in the examples.
13-16

PE1 P1 CE1 CE port 1 DUT P1 P/PE port 1 PE2
CE2
P2
PE3 PE4
CE port 2
P/PE port 2
Figure 13-3. Topology Diagram for Configuration Examples
This section covers the following topics: Example 1: Non-unique VRFs on page 13-17. Example 2: Unique VRFs on page 13-18. CE-to-PE Transmit Stream on page 13-20. PE-to-CE Transmit Stream on page 13-20.
Example 1: Non-unique VRFs

2 CE ports and 2 P ports Each P port has 2 PEs Number of VRFs: 2 Non-unique VRFs Number of Routes: 5 First Route range: 22.22.1.0/24, Increment value: 0.0.1.0.
For non-unique VRFs, the traffic is partially-meshed; each CE port sends traffic to all P/PE ports and each P/PE port sends traffic to all CE ports. PE Port 1
Addresses on PE 1: VRF 1: 22.22.1.0 22.22.2.0 22.22.3.0 22.22.4.0 22.22.5.0 VRF 2: 22.22.6.0 22.22.7.0 22.22.8.0 22.22.9.0 22.22.10.0 VRF 1: 22.22.11.0 22.22.12.0 22.22.13.0 22.22.14.0 22.22.15.0 Addresses on PE 2: VRF 2: 22.22.16.0 22.22.17.0 22.22.18.0 22.22.19.0 22.22.20.0
13-17
13

PE Port 2
CE Ports
Addresses on CE 1: First Router is configured on VRF 1: 22.22.41.0 22.22.42.0 22.22.43.0 22.22.44.0 22.22.45.0 Second Router is configured on VRF 2: 22.22.46.0 22.22.47.0 22.22.48.0 22.22.49.0 22.22.50.0 Addresses on CE 2: First Router is configured on VRF 1: 22.22.51.0 22.22.52.0 22.22.53.0 22.22.54.0 22.22.55.0 Second Router is configured on VRF 2: 22.22.56.0 22.22.57.0 22.22.58.0 22.22.59.0 22.22.60.0
CE-to-PE Transmit Stream A host on the first route on each router transmits to the corresponding VRF on the PE side. For example, on CE 1: 22.22.41.2 transmits to 22.22.1-5, 22.22.11-15, 22.22.21-25, and 22.22.31-35 22.22.46.2 transmits to 22.22.6-10, 22.22.16-20, 22.22.26-30, and 22.22.3640 PE-to-CE Transmit Stream A host on the first PE of each VRF transmits to the corresponding VRF on the CE side. For example: 22.22.1.2 transmits to 22.22.41-45 and 22.22.51-55 22.22.6.2 transmits to 22.22.46-50 and 22.22.51-60
Example 2: Unique VRFs

2 CE ports, 2 P ports Each P port has 2 PEs Number of VRFs: 2 Unique VRFs Number of Routes: 5
13-18

First Route range: 22.22.1.0/24, Increment value: 0.0.1.0.
Total number of VRFs = Number of PE routers * Number of VRFs * Number of P ports. In this example: Total VRFs = 2 * 2 *2 = 8. The traffic is peer to peer. PE Port 1
PE Port 2
CE Port 1
Addresses on CE 1: First Router is configured on VRF 1: 22.22.41.0 22.22.42.0 22.22.43.0 22.22.44.0 22.22.45.0 Second Router is configured on VRF 2: 22.22.46.0 22.22.47.0 22.22.48.0 22.22.49.0 22.22.50.0 First Router is configured on VRF 3: 22.22.51.0 22.22.52.0 22.22.53.0 22.22.54.0 22.22.55.0 Second Router is configured on VRF 4: 22.22.56.0 22.22.57.0 22.22.58.0 22.22.59.0 22.22.60.0
13-19
13

CE Port 2
Addresses on CE 2: First Router is configured on VRF 5: 22.22.61.0 22.22.62.0 22.22.63.0 22.22.64.0 22.22.65.0 Second Router is configured on VRF 6: 22.22.66.0 22.22.67.0 22.22.68.0 22.22.69.0 22.22.70.0 First Router is configured on VRF 7: 22.22.71.0 22.22.72.0 22.22.73.0 22.22.74.0 22.22.75.0 Second Router is configured on VRF 8: 22.22.76.0 22.22.77.0 22.22.78.0 22.22.79.0 22.22.80.0
CE-to-PE Transmit Stream

A host on the first route on each router transmits to the corresponding VRF on the PE side. For example, on CE 1: 22.22.41.2 transmits to 22.22.1-5 22.22.46.2 transmits to 22.22.6-10
PE-to-CE Transmit Stream

A host on the first PE of each VRF transmits to the corresponding VRF on the CE side. For example: 22.22.1.2 transmits to 22.22.41-45 22.22.6.2 transmits to 22.22.46-50
13-20
14
Chapter 14:
VPLS Test Suite
Virtual Private LAN Service (VPLS) is a Layer 2 VPN service that emulates a LAN across an IP-based MPLS network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. This section covers the following topics: Overview of the VPLS Test Suite on page 14-1. DUT Setup on page 14-3. VPLS and Run Parameters on page 14-7. Partially-Meshed Throughput on page 14-13. Peer-to-Peer Throughput on page 14-18. Address Rate on page 14-22. Address Cache on page 14-26.
Overview of the VPLS Test Suite

This section covers the following topics: Benefits of VPLS on page 14-1. How VPLS Works on page 14-2. VPLS Tests on page 14-2.
Benefits of VPLS
VPLS offers several advantages over traditional VPNs. Draft-Martini provides one currently popular MPLS-based VPN solution, but it is limited by its point-topoint nature. While it is possible to create a mesh of point-to-point links, a network structured this way soon runs into scalability problems. RFC2547bis offers an any-to-any VPN solution, but it carries IP traffic. VPLS blends the best features of both, using the widely-adopted Ethernet protocol for fast and efficient Layer 2 connectivity while using a many-to-many connection model.
14-1
14
VPLS Test Suite

Overview of the VPLS Test Suite
In addition to simplifying provisioning and management by using Ethernet from end-to-end, VPLS also improves on other VPN solutions by allowing a customer site to connect to other sites using a single connection to the provider network. Traditional VPNs require each customer site to have a separate connection to the provider network. for each remote site. To a customer, VPLS makes it as easy to connect the LAN networks at disparate sites as if they were all part of one corporate LAN.
How VPLS Works
A VPLS VPN performs many of the same functions as a regular Ethernet-bridged LAN, such as learning, forwarding, and flooding based on MAC addresses. However, it performs these functions not only on the Ethernet physical interfaces but also on MPLS/IP virtual circuits it creates called pseudowires. This enables it to provide a bridged service over MPLS/IP networks with much greater scalability than existing LANs. VPLS learns customer MAC addresses and forwards data packets based on those addresses. To isolate MAC addresses from different customers, it uses separate filtering databases for each customer. To limit the scope of broadcast domains, it uses a separate set of pseudowires for each customer.
Untagged Ethernet frame Preamble SF DA SA T/L Payload FCS CE PE P VPN A CE PE PC P PE CE Tunnel Label VC Label VPN A P CE MPLS core PC P PE Customer Edge router Provider Edge router Provider router VPN A Pseudowires
Traffic to other sites in VPN A
DA
SA
T/L
Payload
FCS
Used by PC routers to switch packet through MPLS core
Identifies correct VPLS
Figure 14-1. Layer 2 MPLS VPN
VPLS Tests
The IxAutomate tests for VPLS are: Partially-Meshed Throughput on page 14-13 analyzes the throughput of a DUT configured as a PE router using VPLS to route traffic to and from customer endpoints (CE). This uses a partial-mesh traffic pattern in which multiple ports transmit to the same destinations.
Peer-to-Peer Throughput on page 14-18 analyzes the throughput of a DUT
configured as a PE router using VPLS to route traffic to and from customer endpoints (CE). This test uses a one-to-one traffic pattern in which each port transmits to a single destination port.
14-2
VPLS Test Suite

DUT Setup
Address Rate on page 14-22 determines the rate at which a VPLS-enabled DUT can learn the MAC addresses of VPLS endpoints. This test uses a oneto-one traffic pattern in which each port transmits to a single destination port. It includes a binary search algorithm to find the highest rate at which the DUT can learn addresses within a given loss tolerance.
Address Cache on page 14-26 determines the maximum number of VPLS
endpoint MAC addresses a VPLS-enabled DUT can retain. This test uses a one-to-one traffic pattern in which each port transmits to a single destination port. It includes a binary search algorithm to find the maximum number of MAC addresses that the DUT can store.
DUT Setup
Table 14-1 on page 14-3 contains an example of how to configure a Cisco router as the DUT for the VPLS tests. Use this example as a guide to configuring your own DUT.
Table 14-1. Task
Sample Cisco DUT Configuration for VPLS Tests Commands mpls ldp logging neighbor-changes l2 vfi vfi10 manual vpn id 10 neighbor 7.7.7.1 encapsulation mpls neighbor 7.7.7.2 encapsulation mpls neighbor 7.7.7.3 encapsulation mpls
1. Create the VSIs.
2. Create the VLAN and add the VFI to the VLAN.
interface Vlan10 no ip address xconnect vfi vfi10
14-3
14
VPLS Test Suite

DUT Setup
Table 14-1. Task
Sample Cisco DUT Configuration for VPLS Tests Commands interface GE-WAN7/4 ip address 40.0.4.1 255.255.255.0 negotiation auto mpls label protocol ldp tag-switching ip mls qos trust dscp
3. Enable LDP on the interface.
4. Configure and enable OSPF or ISIS (not mandatory)
OSPF: router ospf 20 log-adjacency-changes network 40.0.0.0 0.0.255.255 area 0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 ISIS: router isis ixia mpls traffic-eng router-id Loopback222 net 49.1111.1111.1111.1111.1110.00 metric-style wide log-adjacency-changes
Below is presented a configuration sample for Juniper (Kompella test model):

interfaces { fe-0/1/0 { description CE port; vlan-tagging; encapsulation vlan-vpls; unit 0 { encapsulation vlan-vpls; vlan-id 513; family vpls; } } fe-0/1/2 { description PE port; unit 0 { family inet { address 23.10.10.1/24; }
14-4
VPLS Test Suite

DUT Setup
family mpls; } } protocols { mpls { interface all; } bgp { local-as 20; group bgp-vpls { type internal; traceoptions { file bgp-vpls.txt; flag all; } local-address 20.20.20.1; hold-time 300; family inet { unicast; } family inet-vpn { unicast; } family l2vpn { signaling; } export ospf-to-bgp; peer-as 20; neighbor 11.11.11.1; } ospf { export local-to-ospf; area 0.0.0.0 { interface lo0.0 { passive; } interface fe-0/1/2.0 {
14-5
14
VPLS Test Suite

DUT Setup
interface-type p2p; priority 10; hello-interval 10; dead-interval 40; } } } ldp { interface fe-0/1/2.0 { transport-address router-id; } interface lo0.0; } } community target:1:100 members target:1:100; routing-instances { tc1_513 { instance-type vpls; interface fe-0/1/0.0; route-distinguisher 1:100; vrf-target { import target:1:100; export target:1:100; } protocols { vpls { site-range 1000; site site_513 { site-identifier 1; interface fe-0/1/0.0; } } } } }
14-6
VPLS Test Suite

VPLS and Run Parameters

All the VPLS tests share a common set of protocol and Run parameters: Protocol Parameters on page 14-7. Run Parameters on page 14-10.
Protocol Parameters
Table 14-2 lists the common Protocol Parameters for the VPLS tests.
Table 14-2. Parameter Setup/Cleanup Protocols Label Protocol Parameters Description Choose how frequently IxAutomate is to re-initialize the LDP labels during the test: each framesize each trial at the beginning of the test Direction and Rate Parameters Tx Direction Transmit direction for the VPLS learn frames. You can select from the following directions: Bidirectional: A given CE and PE pair transmit to each other. This option tests the DUTs ability to strip or pop MPLS labels from packets going to the CE and while simultaneously applying or pushing MPLS labels packets going to the PE. PE->CE: PE ports transmit to only to CE ports. This option tests the DUTs ability to strip or pop MPLS labels and forward them to the CE. CE->PE: CE ports transmit to only to PE ports. This option tests the DUTs ability to apply or push MPLS labels onto IP packets and forward the resulting MPLS traffic to the PE. Tolerance Max Rate (%) The percentage of transmitted packets which can be lost before packet loss is declared. The maximum rate at which the test transmits the traffic used to apply a load to the DUT. Enter this value as a percentage of the maximum theoretical frame rate. The rate at which the test transmits the traffic used to apply a load to the DUT.
Frames / Second
MAC and VLAN Parameters
14-7
14
VPLS Test Suite

Protocol Parameters (Continued) Description Determines whether the MAC addresses are unique only within a VLAN or unique across all VLANs in the test. Same MAC: The MAC addresses in traffic sent to a VLAN are unique within that VLAN, but the same MAC addresses are used in traffic sent to other VLANs. Unique MAC: The MAC addresses are unique across all VLANs. To create the unique MAC addresses, the test sets the addresses middle octets (octets 3 and 4) to the VLAN ID.
MAC Assignment Mode
Traffic Mode
Select the number and type of VLAN tags added to the traffic: VLAN Based: Frames include only a single 802.1Q VLAN tag. QinQ: Frames include an 802.1Q tag and a second VLAN tag added as a service delimiter. Port Based: Frames include an 802.1Q tag and a second VLAN tag.
Delay before transmitting frames. This delay allows the DUT time to configure itself and to finish forwarding frames from the previous iteration before receiving frames for the next iteration. Select which ports simulate multiple hosts: CE: The CE ports simulate multiple hosts. CE-to-PE traffic has different source MAC addresses but the same destination MAC address. PE-to-CE traffic has the same source MAC address and different destination MACs. PE: The PE ports simulate multiple hosts. CE-to-PE traffic has the same source MAC addresses but different destination MAC addresses. PE-to-CE traffic has different source MAC addresses and the same destination MAC.
Multiple Hosts On
First VLAN ID
Value of the first VLAN tag applied to VLAN-tagged traffic. The test maps VLAN tags to VCs on a one-toone basis, with the value of the VLAN tag increasing as the number of VCs increases. Number of hosts to simulate on each VLAN.
No. of Hosts per VLAN
14-8
VPLS Test Suite

Protocol Parameters (Continued) Description First VLAN ID in reserved range. Some devices reserve a range of VLAN IDs for their own internal use. You can use the Start and End Reserved VLAN ID parameters to define this range. When you run the test, it skips the reserved VLAN IDs when it transmits. Last VLAN ID in reserved range.
Start Reserved VLAN ID
MAC Learn Frame Parameters Frequency Determines when the test sends the MAC Learn frames. On Trial: The test sends MAC Learn frames before the start of each trial. Never: The test never sends MAC Learn frames. Frames to Each Host Rate Table Size Age Traffic Mix Parameters Unicast CE-to-CE Percentage Enter the percentage of the total traffic that is unicast traffic. This parameter allows you to configure a portion of the traffic from each CE to be sent to the other CEs in the test. (Figure 14-2 on page 14-10). This portion of traffic is ordinary (not VLAN-tagged) Ethernet frames. Enter the percentage of the total traffic that is broadcast traffic. Enter the ID of the initial VSI (Virtual Switch Instance) for broadcast traffic. A VSI is the entity that performs MAC address learning, forwarding and flooding for a particular VC. Enter the total number of VSIs used for broadcast traffic. Enter the percentage of the total traffic that is multicast traffic. Enter the initial VSI for multicast traffic. Enter the number of VSI used for multicast traffic. Number of MAC Learn frames sent to each host. Rate at which the test sends MAC Learn frames. Number of entries in the DUTs VPLS FIB (MAC address table). Age-out time of DUTs VPLS FIB.
Broadcast Start VSI
VSI Count Multicast Start VSI VSI Count
14-9
14
VPLS Test Suite

Table 14-2. Parameter Rogue
Protocol Parameters (Continued) Description Enter the percentage of the total traffic that is rogue traffic. Rogue traffic is traffic to or from MAC addresses other than those that have already been learned on VLAN. The test creates rogue traffic by incrementing the highest-numbered MAC Address used in the test. Enter the ID of the initial VSI for rogue traffic. Enter the total number of VSIs used for rogue traffic.
Start VSI VSI Count
Send Unicast Frames on Some VPLS Parameters Enable If you enable this option, the test transmits unicast traffic over VSIs that would otherwise carry only multicast or broadcast traffic. Specify the first VSI to carry unicast traffic in addition to other traffic. Enter the total number of VSIs to carry unicast traffic.
Start Unicast VSI Unicast VSI Count
CE
VPN A
VPN A CE port 1 CE port 2 VPN B
CE PE port 1 DUT CE PE port 2
CE-to-CE Percentage traffic ------------------------------------CE Port 1 --> CE Port 2 CE Port 2 --> CE Port 1 CE
VPN B PC
Figure 14-2. CE-to-CE Percentage (Partial-Mesh Transmission Shown)
Run Parameters
Table 14-3 lists the common Run Parameters for the VPLS tests.
14-10
VPLS Test Suite

Run Parameters for VPLS Tests Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10.
No. of Trials
Calibrate Latency
Test Type LDP Based (LasserreV. Kompella Draft) This test type uses: LDP protocol as signaling protocol OSPF protocol or ISIS protocol as internal protocol no discovery protocol This test type uses: BGP as signaling protocol OSPF protocol or ISIS protocol as internal protocol BGP as discovery protocol
BGP L2VPN (Kompella Draft)
VPLS Parameters No. of PEs per Port No. of VCs per PE Number of PE routers simulated on each PE port. Number of Virtual Circuits each simulated PE establishes with the DUT. The DUT must be configured to establish the same number of VCs as the Ixia port. Label of the first VC established with the DUT. It identifies correct VPLS. Maximum Transfer Unit. Maximum length of data that can be contained within a frame. This setting must match the MTU setting on the DUT. Timeout for receiving configuration information or updates from the DUT. If the Ixia port does not receive configuration information within the configured time, the test stops. First IP address used to establish LDP session with DUT. ID of the first VC established with the DUT. The DUT must be configured to establish VCs starting from this ID.
First VC Label MTU Size
Max Wait Time
First PE Loopback IP First VC ID
14-11
14
VPLS Test Suite

Run Parameters for VPLS Tests (Continued) Description Internal loopback address on the simulated CE router. The DUT must be configured to use this address as a tunnel endpoint. The first label in the range of MPLS labels.
Peer IP Address
First Tunnel Label OSPF Parameters Interface Network Type
Area ID ISIS Parameters Level
You can configure the router to act as a: Level 1 (intra-area) router. A Level 1 router is a router in a non-backbone area. Level 1+2 router connects areas. It connects a Level 1 area to the Level 2 backbone. Level 2 router (inter-area) these routers are connected only to the backbone and provide transit traffic between areas.
Link Type
Select one of the following circuit types used by link state routing protocols: Broadcast Point to Point
Wide Metrics
Choose one of the available options (yes or no) to display the wide metrics as results or not.
BGP Protocol: BGP Router Local AS Number 1st Route Target (AS: Assigned) Route Target Assigned Step The Autonomous System number associated with the simulated BGP router. It is defined by two numbers: the autonomous system number (AS) and the assigned number. The default value for AS is 1 and for Assigned is 100. Increment value for the Assigned field over the route target values. The default is 1.
BGP Protocol: Extra VPLS Settings Site ID Start Site ID Increment Label Block Size The first L2 Site ID. Incremented value for the Site ID which allows the input of discontinuous values as site ID. The number of labels contained in the Label Block. The default is 100.
14-12
VPLS Test Suite

Partially-Meshed Throughput
Run Parameters for VPLS Tests (Continued) Description The first label value included in set of contiguous labels in the Label Block. The default is 1.
Block Offset Start
Block Offset Step
Increment value for the block offset over the L2 VPN sites. The default is 1.
This section covers the following topics: Overview on page 14-13. Configuring the Test Parameters on page 14-14. Test Cycle on page 14-14
Overview
This test analyzes the throughput of a DUT configured as a PE router using VPLS to route traffic to and from customer endpoints (CE). This uses a partiallymeshed traffic pattern in which multiple ports transmit to the same destinations. A traffic mix of unicast, broadcast, and multicast traffic can be defined to determine packet loss at a specified rate. The test can send either bidirectional or unidirectional traffic. You can select to use OSPF or ISIS as internal protocol. You can choose to run one of the two available test types: LDP Based (Lassarre-V. Kompella Draft) BGP L2VPN (Kompella Draft)
Depending on the test type, different DUT configurations are necessary. The test includes a binary search algorithm to find the highest rate at which the DUT can absorb frames within a given loss tolerance. Ixia ports simulate CE routers and other PE routers in a service provider network. The CE ports can transmit traffic that simulates traffic originating from a single customer (a direct port-to-port link between CE and PE) or from multiple customers, in which case the traffic is differentiated by VLAN IDs. The simulated PEs are also remote VPLS sites. Each of these VPLS sites has a range of Ethernet MAC addresses associated with it and optionally, a VLAN tag. The DUT and the simulated PEs build VCs between each other.
14-13
14
VPLS Test Suite

VPLS Partially-Meshed Throughput test
Traffic Directions: Bidirectional PE --> CE CE --> PE CE VPN A
PE
Simulated service provider OSPF/ISIS + MPLS network PE LDP session MPLS Tunnels / VCs
P VPN A CE port 1 CE port 2 VPN B CE CE
PE PE port 1
DUT
PE PE
PE port 2
PE
PE PC VPN B
CE
Figure 14-3. VPLS Partially-Meshed Test
Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 14-3 on page 14-11. Protocol parameters: see Table 14-2 on page 14-7.
Test Cycle
The test algorithm is available for both test types. Some different settings available for the BGP L2VPN (Kompella Draft) test type are described in BGP L2 VPN (Kompella Draft) Required Settings on page 14-16. When the test starts, the CE and PE ports send ARP frames to the DUT so that it can populate its ARP table. It then starts OSPF/ISIS and LDP on the PE ports. OSPF/ISIS advertises one route range for each of the simulated PE/VPLS routers. The test waits for (depending on the internal protocols chosen): the OSPF neighbors to reach Full State or ISIS to finish advertising the route prefixes of the simulated ISIS networks to the DUT and for the LDP Basic Sessions and Targeted Sessions to come up.
14-14
VPLS Test Suite

The CE ports then transmit a series of frames, each bearing the MAC addresses of one of the simulated PE/VPLS routers. The DUT then looks up each MAC address in its VPLS Forwarding Information Base (FIB), which records the associations between MAC addresses and VC LSPs. If it finds the MAC address in the VPLS FIB, the DUT encapsulates the frame as an MPLS packet, pushes an inner VC label and outer tunnel label onto the packet, and sends the packet out on the VC LSP associated with the MAC address. The packet travels over a tunnel LSP to the VC peer (the simulated destination PE). If the DUT does not find the MAC address in its VPLS FIB, it floods the frame to all the simulated PE devices and other CE ports (except for the CE port that originated the frame) in the VPLS configuration. When it receives a response, it adds an entry to its VPLS FIB recording the MAC address and the VC it arrived on. Any future frames that arrive with the same MAC address are sent out the corresponding VC. After the test has sent the frames to enable the DUT to populate its VPLS FIB, it begins transmitting load-test traffic -- the frames that simulate actual customer traffic. If you selected the CE--> PE for the Traffic Direction, each CE port transmits to every PE port. If you selected the PE--> CE, each PE port transmits to every CE port. If you selected Bidirectional, the test transmits in the CE--> PE and PE --> CE directions simultaneously.
Partial-mesh Transmission Pattern (CE --> PE direction)
CE
VPN A
CE
VPN B PC
Figure 14-4. Partially Meshed
It transmits at the rate specified by Max Rate or Frames / Second (whichever one you selected). The Traffic Type Rate parameters define the percentages of unicast, broadcast, multicast, and rogue frames that make up the total traffic mix.
14-15
14
VPLS Test Suite

After the first iteration is complete, the test measures the packet loss and compares it with the Loss Tolerance value. If the packet loss was within the Loss Tolerance, the test increases the transmit rate and runs another iteration. If packet loss exceeded the Loss Tolerance, the test reduces the transmit rate and runs another iteration.
After the second iteration, the test again checks for packet loss. It applies a binary search algorithm to calculate a new transmit rate based on the previous rates and presence or absence of packet loss. It goes through this same process for every subsequent iteration until it finds the highest rate at which the DUT can absorb frames within the Loss Tolerance.
BGP L2 VPN (Kompella Draft) Required Settings

If choosing to run a BGP L2 VPN Kompella Draft test, the streams configuration and the algorithm logic remain unchanged. The following settings are required: specify the input number of VE (PE) routers per Ixia port and advertise the user input number of routes accordingly enable the BGP protocol LDP protocol should be configured only for basic sessions on the Ixia PE ports BGP routers configured to exchange required L2 VPN site information: a: For each PE port, you should configure a number of BGP neighbors equal with the number of PE routers as set on the Test Setup tab b: For each of these neighbors, you should configure a number of L2 VPN sites equal with the number of CE devices emulated, with their corresponding label blocks (1 per device) Instead of collecting the Martini labels, the received L2 VPN Label Block information is collected and if the received information is correct, the corresponding labels are extracted and used further in the same way as the Martini labels, in the streams, to generate the corresponding traffic.
Pass/Fail Criteria

Table 14-4. Parameter Pass Criteria VPLS Partially Meshed Throughput Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
14-16
VPLS Test Suite

VPLS Partially Meshed Throughput Test - Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Data Errors
14-17
14
VPLS Test Suite

Peer-to-Peer Throughput
Test Results
For each iteration, the test records the following results: Total Frames Transmitted Total Frames Received Total Frames Expected to be Received Total Packet Loss (%) Throughput as a percentage of maximum frame rate Throughput in frames per second Average Latency (ns) Data Errors
Following the final iteration, the test also creates two summary reports: one that summarizes the results by trial and another one that summarizes them according to frame size.
This section covers the following topics: Overview on page 14-18. Configuring the Test Parameters on page 14-19. Test Cycle on page 14-19. Pass/Fail Criteria on page 14-21. Test Results on page 14-22.
Overview
This test analyzes the throughput of a DUT configured as a PE router using VPLS to route traffic to and from customer endpoints (CE). This test uses a oneto-one traffic pattern in which each port transmits to a single destination port. It includes a binary search algorithm to find the highest rate at which the DUT can absorb frames within a given loss tolerance. You can select to use OSPF or ISIS as internal protocol. You can choose to run one of the two available test types: LDP Based (Lassarre-V. Kompella Draft) BGP L2VPN (Kompella Draft)
Depending on the test type, different DUT configurations are necessary. Ixia ports simulate CE routers and other PE routers in a service provider network. The CE ports can transmit traffic that simulates traffic originating from a single customer (a direct port-to-port link between CE and PE) or from multiple customers, in which case the traffic is differentiated by VLAN IDs.
14-18
VPLS Test Suite

The simulated PEs are also remote VPLS sites. Each of these VPLS sites has a range of Ethernet MAC addresses associated with it and optionally, a VLAN tag. The DUT and the simulated PEs build VCs between each other.
VPLS Peer-to-Peer Throughput test
Traffic Directions: Bidirectional PE --> CE CE --> PE CE CE port PE port VPN A
PE
Simulated service provider OSPF/ISIS + MPLS network PE LDP session MPLS Tunnels / VCs PE
VPN A
CE
DUT
PE
Figure 14-5. VPLS Peer-to-Peer Throughput Test
Test Cycle
The test algorithm is available for both test types: LDP Based (Lassarre-V. Kompella Draft) and BGP L2VPN (Kompella Draft). Some different settings available for the BGP L2VPN (Kompella Draft) test type are described in BGP L2 VPN (Kompella Draft) Required Settings on page 14-16. When the test starts, the CE and PE ports send ARP frames to the DUT so that it can populate its ARP table. It then starts OSPF/ISIS and LDP on the PE ports. OSPF/ISIS advertises one route range for each of the simulated PE/VPLS routers. The test waits for (depending of the internal protocols chosen): the OSPF neighbors to reach Full State or ISIS to finish advertising the route prefixes of the simulated ISIS networks to the DUT
and for the LDP Basic Sessions and Targeted Sessions to come up. The CE ports then transmit a series of frames, each bearing the MAC addresses of one of the simulated PE/VPLS routers. The DUT then looks up each MAC address in its VPLS Forwarding Information Base (FIB), which records the associations between MAC addresses and VC LSPs.
14-19
14
VPLS Test Suite

If it finds the MAC address in the VPLS FIB, the DUT encapsulates the frame as an MPLS packet, pushes an inner VC label and outer tunnel label onto the packet, and sends the packet out on the VC LSP associated with the MAC address. The packet travels over a tunnel LSP to the VC peer (the simulated destination PE). If the DUT does not find the MAC address in its VPLS FIB, it floods the frame to all the simulated PE devices and other CE ports (except for the CE port that originated the frame) in the VPLS configuration. When it receives a response, it adds an entry to its VPLS FIB recording the MAC address and the VC it arrived on. Any future frames that arrive with the same MAC address are sent out the corresponding VC. After the test has sent the frames to enable the DUT to populate its VPLS FIB, it begins transmitting load-test traffic -- the frames that simulate actual customer traffic. If you selected the CE--> PE for the Traffic Direction, traffic flows from a CE port to its corresponding PE port. If you selected the PE--> CE, traffic flows from a PE port to its corresponding CE port. If you selected Bidirectional, the traffic flows in the CE--> PE and PE --> CE directions simultaneously.
Peer-to-peer Transmission Pattern (CE --> PE direction)
CE
VPN A
CE
VPN B PC
Figure 14-6. One-to-One Transmission Pattern
It transmits at the rate specified by Max Rate or Frames / Second (whichever one you selected). The Traffic Type Rate parameters define the percentages of unicast, broadcast, multicast, and rogue frames that make up the total traffic mix. After the first iteration is complete, the test measures the packet loss and compares it with the Loss Tolerance value. If the packet loss was within the Loss Tolerance, the test increases the transmit rate and runs another iteration. If packet loss exceeded the Loss Tolerance, the test reduces the transmit rate and runs another iteration.
14-20
VPLS Test Suite

After the second iteration, the test again checks for packet loss. It applies a binary search algorithm to calculate a new transmit rate based on the previous rates and presence or absence of packet loss. It goes through this same process for every subsequent iteration until it finds the highest rate at which the DUT can absorb frames within the Loss Tolerance.
Pass/Fail Criteria

Table 14-5. Parameter Pass Criteria VPLS Peer-to-Peer Throughput Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
14-21
14
VPLS Test Suite

Address Rate
VPLS Peer-to-Peer Throughput Test - Pass/Fail Criteria (Continued) Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors is less than or equal to the value you entered. Fail: The number of frames received with errors is greater than the number you entered.
Test Results
For each iteration, the test records the following results: Total Frames Transmitted Total Frames Received Total Frames Expected to be Received Total Packet Loss (%) Throughput as a percentage of maximum frame rate Throughput in frames per second Average Latency (ns) Data Errors
Following the final iteration, the test also creates two summary reports: one that summarizes the results by trial and another that summarizes them according to frame size.
Address Rate
This section covers the following topics: Overview on page 14-22. Configuring the Test Parameters on page 14-23. Test Cycle on page 14-24. Pass/Fail Criteria on page 14-25. Test Results on page 14-26.
14-22
VPLS Test Suite

Address Rate
Overview
This test determines the rate at which a VPLS-enabled DUT can learn the MAC addresses of VPLS endpoints. This test uses a one-to-one traffic pattern in which each port transmits to a single destination port. This test requires at least four ports to run. It includes a binary search algorithm to find the highest rate at which the DUT can learn addresses within a given loss tolerance. You can select to use OSPF or ISIS as internal protocol. You can choose to run one of the two available test types: LDP Based (Lassarre-V. Kompella Draft) BGP L2VPN (Kompella Draft)
Depending on the test type, different DUT configurations are necessary. Ixia ports simulate CE routers and other PE routers in a service provider network. The CE ports can transmit traffic that simulates traffic originating from a single customer (a direct port-to-port link between CE and PE) or from multiple customers, in which case the traffic is differentiated by VLAN IDs. The simulated PEs are also remote VPLS sites. Each of these VPLS sites has a range of Ethernet MAC addresses associated with it and optionally, a VLAN tag. The DUT and the simulated PEs build VCs between each other.
VPLS Address Rate test
Traffic Direction: CE --> PE VPLS ------FIB ---------------PE CE VPN A
Simulated service provider OSPF/ISIS + MPLS network PE LDP session MPLS Tunnels / VCs
VPLS Learn frames PE PE port 1
DUT
PE PE
PE port 2
PE
PE PC VPN B
CE
Figure 14-7. VPLS Address Rate Test
Frame Size: see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23.
14-23
14
VPLS Test Suite

Address Rate
Traffic Mapping: see Setting Up the Traffic Map on page 3-11. Run parameters: see Table 14-3 on page 14-11. Protocol parameters: see Table 14-2 on page 14-7.
Test Cycle
and for the LDP Basic Sessions and Targeted Sessions to come up. The CE ports then transmit a series of frames, each bearing the MAC addresses of one of the simulated PE/VPLS routers. The DUT then looks up each MAC address in its VPLS Forwarding Information Base (FIB), which records the associations between MAC addresses and VC LSPs. If it finds the MAC address in the VPLS FIB, the DUT encapsulates the frame as an MPLS packet, pushes an inner VC label and outer tunnel label onto the packet, and sends the packet out on the VC LSP associated with the MAC address. The packet travels over a tunnel LSP to the VC peer (the simulated destination PE). If the DUT does not find the MAC address in its VPLS FIB, it floods the frame to all the simulated PE devices and other CE ports (except for the CE port that originated the frame) in the VPLS configuration. When it receives a response, it adds an entry to its VPLS FIB recording the MAC address and the VC it arrived on. Any future frames that arrive with the same MAC address are sent out the corresponding VC. After the test has sent the frames to enable the DUT to populate its VPLS FIB, it begins transmitting load-test traffic, the frames that simulate actual customer traffic, in the CE --> PE direction. It transmits at the rate specified by Max Rate or Frames / Second (whichever one you selected). After the first iteration is complete, the test checks to see if the DUT flooded any frames. If it did, the test assumes the DUT failed to learn those frames addresses. The test measures the number of unlearned addresses and compares it with the Loss Tolerance value.
14-24
VPLS Test Suite

Address Rate
If the number of unlearned addresses was within the Loss Tolerance, the test increases the rate at which it transmits MAC addresses to the DUT (MAC Learn Frames Rate parameter) and runs another iteration. If the number of unlearned addresses exceeded the Loss Tolerance, the test reduces the MAC address transmit rate and runs another iteration.
While the test checks for flooding, it also waits for the DUT to age-out its VPLS FIB. After the age-out time has elapsed, the test again transmits MAC addresses to the DUT, followed by the load-test traffic. After the second iteration, the test again checks for unlearned addresses. It applies a binary search algorithm to calculate a new transmit rate based on the previous rates and the number of unlearned addresses. It goes through this same process for every subsequent iteration until it finds the highest rate at which the DUT can learn addresses within the Loss Tolerance.
Pass/Fail Criteria

Table 14-6. Parameter Pass Criteria VPLS Address Rate Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
14-25
14
VPLS Test Suite

Address Cache
VPLS Address Rate Test - Pass/Fail Criteria (Continued) Description Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Data Errors
Test Results
For each iteration, the test records the following results: Total Frames Transmitted Total Frames Received Throughput as a percentage of maximum frame rate Throughput in frames per second Data Errors
Following the final iteration, the test also calculates a summary of the results.
Address Cache
This section covers the following topics: Overview on page 14-27. Configuring the Test Parameters on page 14-28.
14-26
VPLS Test Suite

Address Cache
Test Cycle on page 14-28. Pass/Fail Criteria on page 14-30. Test Results on page 14-30.
Overview
This test determines the maximum number of VPLS endpoint MAC addresses a VPLS-enabled DUT can retain. This test uses a one-to-one traffic pattern in which each port transmits to a single destination port. This test requires at least four ports to run. It includes a binary search algorithm to find the maximum number of MAC addresses the DUT can store. You can select to use OSPF or ISIS as internal protocol. You can choose to run one of the two available test types: LDP Based (Lassarre-V. Kompella Draft) BGP L2VPN (Kompella Draft)
Depending on the test type, different DUT configurations are necessary. Ixia ports simulate CE routers and other PE routers in a service provider network. The CE ports can transmit traffic that simulates traffic originating from a single customer (a direct port-to-port link between CE and PE) or from multiple customers, in which case the traffic is differentiated by VLAN IDs. The simulated PEs are also remote VPLS sites. Each of these VPLS sites has a range of Ethernet MAC addresses associated with it and optionally, a VLAN tag. The DUT and the simulated PEs build VCs between each other.
VPLS Address Cache test
Traffic Direction: CE --> PE VPLS FIB - - - ------ - - ------ - - -----PE CE VPN A
Simulated service provider OSPF/ISIS + MPLS network PE LDP session
PE PE port 1
DUT
PE PE
PE port 2
PE
PE PC VPN B
CE
Figure 14-8. VPLS Address Cache Test
14-27
14
VPLS Test Suite

Address Cache
Test Cycle
and for the LDP Basic Sessions and Targeted Sessions to come up. The CE ports then transmit a series of learning frames, each bearing the MAC addresses of one of the simulated PE/VPLS routers. The DUT then looks up each MAC address in its VPLS Forwarding Information Base (FIB), which records the associations between MAC addresses and VC LSPs. If it finds the MAC address in the VPLS FIB, the DUT encapsulates the frame as an MPLS packet, pushes an inner VC label and outer tunnel label onto the packet, and sends the packet out on the VC LSP associated with the MAC address. The packet travels over a tunnel LSP to the VC peer (the simulated destination PE). If the DUT does not find the MAC address in its VPLS FIB, it floods the frame to all the simulated PE devices and other CE ports (except for the CE port that originated the frame) in the VPLS configuration. When it receives a response, it adds an entry to its VPLS FIB recording the MAC address and the VC it arrived on. Any future frames that arrive with the same MAC address are sent out the corresponding VC. After the test has sent the learning frames to enable the DUT to populate its VPLS FIB, it begins transmitting load-test traffic, the frames that simulate actual customer traffic, in the CE --> PE direction. It transmits at the rate specified by Max Rate or Frames / Second (whichever one you selected).
14-28
VPLS Test Suite

Address Cache
After the first iteration is complete, the test checks to see if the DUT flooded any frames. If it did, the test assumes the DUT failed to learn those frames addresses. The test measures the number of unlearned addresses and compares it with the Loss Tolerance value. If the number of unlearned addresses was within the Loss Tolerance, the test increases the number of MAC addresses it sends to the DUT (MAC Learn Frames Rate parameter) and runs another iteration. If the number of unlearned addresses exceeded the Loss Tolerance, the test reduces the number of MAC addresses and runs another iteration.
While the test checks for flooding, it also waits for the DUT to age out its VPLS FIB. After the age-out time has elapsed, the test again transmits learning frames with MAC addresses to the DUT, followed by the load-test traffic. After the second iteration, the test again checks for unlearned addresses. It applies a binary search algorithm to calculate the number of MAC addresses to send based on the previous numbers sent and the number of unlearned addresses. It goes through this same process for every subsequent iteration until it finds the largest number MAC addresses the DUT can retain within the Loss Tolerance.
14-29
14
VPLS Test Suite

Address Cache
Pass/Fail Criteria

Table 14-7. Parameter Pass Criteria VPLS Address Cache Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The numerical threshold value for the number of learned MAC addresses. Pass: The table size was equal to or greater than the number you entered. Fail: The table size was less than the number you entered.
Table Size
Test Results
For each iteration, the test records the following results: Total Frames Transmitted Total Frames Received Throughput as a percentage of maximum frame rate Throughput in frames per second Data Errors
Following the final iteration, the test also calculates a summary of the results.
14-30
15
Chapter 15:
Label Distribution Protocol (LDP) Test Suite

Overview of the Label Distribution Protocol (LDP) Test Suite on page 15-2. DUT Setup on page 15-3.
The IxAutomate tests for LDP are:

Egress Partially Meshed Performance Test on page 15-4 is similar to the
Egress Performance test except that it allows you to use a partial-mesh configuration and does not perform a binary search. Egress Performance Test on page 15-11 determines the maximum rate at which an LDP router can strip LDP labels from labeled packets and forward the resulting IP traffic with no loss.
Ingress Partially Meshed Performance Test on page 15-18 is similar to the
Ingress Performance test except that it allows you to use a partial-mesh configuration and does not perform a binary search. Ingress Performance Test on page 15-24 determines the maximum rate at which an LDP router can apply LDP labels to IP traffic and forward the labeled traffic with no loss. Transit Performance Test on page 15-30 determines the maximum rate at which a label-switching router can receive packets, swap their labels, and forward them with no loss.
Note: Some of the LDP tests require the Value List UDF feature, which is not available on all load modules. If you try to run an LDP test and find that IxAutomate drops one or more ports from the test, refer to the Ixia Hardware Guide and check to make sure that the ports support Value List UDFs.
15-1
15

Overview of the Label Distribution Protocol (LDP) Test Suite
Overview of the Label Distribution Protocol (LDP) Test Suite

Label Distribution Protocol (LDP) is a protocol for distributing labels in MPLS (Multi-Protocol Label-Switching) networks. MPLS requires some type of label distribution protocol as a way for Label Switched Routers (LSRs) to inform each other of which labels they should use to forward traffic between and through them. A label identifies the path a packet should traverse through the MPLS network. Labels are encapsulated in a Layer 2 header along with the packet payload. Once a packet enters the network and receives its label, the rest of its journey through the backbone is based on label-switching; when a router receives a packet, it checks the contents of the label to determine the next hop. Labels have local significance only; they only identify the hops between LSRs. MPLS does not mandate the use of a particular label distribution protocol. Consequently, a number of different label distribution protocols are being standardized. Some are existing protocols that have been extended to include label distribution. Others are new protocols specifically created for distributing labels. Defined in RFC 3031, LDP consists of procedures and messages which LSRs use to establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths. The LSPs may have an endpoint at a directly-attached neighbor (similar to IP hop-byhop forwarding), or they may have an endpoint at a network egress node (Label Edge Router, LER), enabling switching by all the nodes in between.
LSP
Label Request for path to Router C Ingress Router A (Ingress LER)
Label Request for path to Router C Response: 'Use Label 456' Egress Router C (Egress LER)
Transit Response: 'Use Label 123' Router B Transit LSR (DUT) MPLS domain
Figure 15-1. LDP
15-2

DUT Setup
DUT Setup
The DUT must be configured as follows: OSPF must be enabled and configured MPLS must be enabled and configured, with the DUT as a Transit LSR LDP must be enabled and configured
Table 15-1 lists the Cisco IOS commands necessary to configure LDP.
Because the MPLS throughput test uses the DUT as a Transit LSR, you must configure two ports.
Table 15-1. Command Router(config)#interface fast 0/0/0 Router(config-if)#null Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fast 0/0/1 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fastEthernet 0/0/0 Router(config-if)#mpls label protocol ldp Router(config-if)#mpls ldp discovery transport-address interface Router(config-if)#ip ospf network broadcast Router#router ospf 10 Router(config-router)#network 10.10.0.0 0.0.255.255 area 0 Router(config-if)#mpls ip Router(config-if)#mpls label protocol ldp Router(config-if)#mpls ldp Configure the LDP transport address Configure the OSPF network as a broadcast network Enable OSPF and define the OSPF area Enable LDP on the interface Cisco LDP/OSPF Configuration Description Configure the general interface properties
Configure the IP addresses, LDP and OSPF.
15-3
15

Egress Partially Meshed Performance Test
Table 15-1. Command
Cisco LDP/OSPF Configuration (Continued) Description
Router(config)#interface ethernet 1/0/6 Assign an IP address to an interface Router(config-if)#ip address 11.12.11.1 255.255.255.0 Router(config-if)#mpls ip Router(config-if)#mpls label protocol ldp Configures MPLS hop-by-hop forwarding for a specified interface Configures the use of LDP for a specific interface.
Router(config)#interface ethernet 1/0/7 Assign an IP address to an interface Router(config-if)#ip address 11.12.12.1 255.255.255.0 Router(config-if)#mpls ip Router(config-if)#mpls label protocol ldp Router(config)#router ospf 10 Router(config-router)#network 11.12.0.0 0.0.255.255 area 0 Router(config-router)#exit Router(config)#interface ethernet 1/0/5 Configure OSPF broadcast on the interface Router(config-if)#ip ospf network broadcast Router(config-if)#exit Router(config)#interface ethernet 1/0/6 Configure OSPF broadcast on the interface Router(config-if)#ip ospf network broadcast Router(config)#interface ethernet 1/0/7 Configure OSPF broadcast on the interface Router(config-if)#ip ospf network broadcast Configures MPLS hop-by-hop forwarding for a specified interface Configures the use of LDP for a specific interface. Enable OSPF and define the OSPF area

This section covers the following topics: Overview on page 15-4. Test Parameters on page 15-6. Pass/Fail Criteria on page 15-8. Test Results on page 15-10.
Overview
This test determines the throughput of an LDP router. It is similar to the Egress Performance Test on page 15-11, except that it allows you to use a partial-mesh port configuration (transmit ports transmit to the same receive ports) and does not perform a binary search to find the maximum no-loss rate.
15-4

To begin the test a Label Switching Path (LSP) is built either from an Ixia transmit port to DUT (when the DUT is configured as a Label Edge Router), or from an Ixia port to an Ixia port (when the DUT is configured as a penultimate (PHP) router). Also, an OSPF session is built on the egress DUT ports for packet routing. Using a grid technique, Route Ranges can define large numbers of OSPF routes quickly. If the DUT is configured as an Egress LER, it must forward the traffic out the correct port to another network simulated by the Ixia receive port. If the DUT is configured as a PHP (Penultimate Hop Popping) router, it must strip ('pop') the label from the label packets, and the forward the traffic along the correct LSP to the edge router simulated by the Ixia receive port.
IP test traffic is configured with MPLS labels attached. MPLS traffic is transmitted from the Ixia port to the DUT, which then strips the labels and forwards the traffic out. Traffic is transmitted at a predefined rate, along with a step value to iterate the test. Port mapping for this test is partially meshed, meaning that transmit ports transmit traffic to the same receive ports in a many-to-many fashion.
DUT Type = Egress LER
standard IP traffic
labeled IP traffic
OSPF
CE
Egress Egress DUT Egress LER
LDP
Ingress LER
DUT Type = PHP
standard IP traffic
labeled IP traffic
LDP
Egress LER
OSPF
PHP DUT PHP
LDP
Ingress LER
DUT Type = PHP
Ixia simulated CE
standard IP traffic
Ixia simulated Egress LER
standard IP traffic LSP
Egress LSP Ixia simulated Ingress LER
Labels stripped from traffic LSP Ixia simulated Ingress LER
PHP
Labels stripped from traffic DUT configured as PHP router
DUT configured as Egress LER
Ixia ports
IP traffic prefixed with labels
Ixia ports
Figure 15-2. Egress Partially Meshed Performance Test
The test initially transmits at the rate you specify. If the packet loss is within the loss tolerance, the test retransmits at a higher rate. The test continues transmitting
15-5
15

at progressively higher rates until the packet loss exceeds the Loss Tolerance, at which point the test ends and prints the results. The test results for each frame size are divided into per-port and per-group results: For each port, the results show: Transmit rate in f/s Transmit rate as a percentage of port speed
For each group, the results show: Lowest, highest, and average latencies Data errors (bad CRC, etc.) Number of small, large, reverse, and total Sequence Errors
The results for all trials include: Average transmit rate in f/s Average transmit rate as a percentage of port speed
Test Parameters
Table 15-2 describes the test parameters.

Table 15-2. Parameter Duration LDP Egress Partially Meshed Performance Test Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Init. Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. Amount added to Init. Rate at the start of each new iteration. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10.
No. of Trials
Loss Tolerance
Increment Calibrate Latency
15-6

LDP Egress Partially Meshed Performance Test Parameters (Continued) Description Number of labels in the stack below the label used for routing across the network. Multiple labels can be used in service provider networks which have tunnels that reach from one edge router (PE) to another. If the tunnels carry traffic from different VPNs, the outer label identifies the LSP between the edge routers, and the inner label identifies the specific VPN. This parameter is only available when you set DUT Type to PHP.
Extra Inner Labels
First Inner Label
Value of the first label inserted below the LSP routing label. To assign values to the second and subsequent labels, the test increments the value for First Inner Label. For example, if: First Inner Label = 100 and Number of Inner Labels = 3 the test inserts 3 consecutively-numbered labels below the LSP routing label. The first label inserted has the value 100, the next- lower label, 101, and the next, 102. This parameter is only available when you set DUT Type to PHP.
MPLS Label TTL DUT Type
Time-to-Live value of the MPLS label. DUTs function and logical position on the LSP within the test network. PHP: If you select PHP, the test sends traffic to the DUT that includes a label whose value is 0 (IPv4 explicit null). Egress LER: If you select Egress LER the test sends traffic to the DUT that includes a label whose value is 3 (IPv4 implicit null).
OSPF Parameters Network Range Size of simulated network. The test multiplies the values you enter for Rows and Column to create a matrix of simulated nodes. Rows: Number of rows in the matrix Columns: Number of columns in the matrix Number of Subnets Number of subnets in the simulated matrix of nodes. This value is calculated automatically by the test.
15-7
15

Table 15-2. Parameter Area ID
LDP Egress Partially Meshed Performance Test Parameters (Continued) Description The area ID associated with the simulated OSPF interfaces on the Ixia ports. The DUT must belong to the same area. Specify the OSPF network type that you want to simulate: If you are using a POS load module, select Point-topoint. If you are using an Ethernet load module, select Broadcast.
Interface Network Type
Advertise Delay per Subnet Label Wait Time per Port
Enter the number of seconds per subnet that the test waits before advertising the routes to the DUT. Value used to calculate how long the test waits for labels. The test multiplies the value you enter by the number of transmit ports to calculate the wait time. If the wait time expires before the test receives all the labels, the test stops. Length of time before the test begins transmitting. This delay allows the DUT to finish LDP setup at the beginning of the test. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously.
DUT Processing Delay
Staggered Transmit
Pass/Fail Criteria

Table 15-3. Parameter Pass Criteria LDP Egress Partially Meshed Performance Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
15-8

LDP Egress Partially Meshed Performance Test - Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Sequence Errors
The number of frames received with sequence errors. You can select either of two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the biggest number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was less than or equal to the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered.
15-9
15

LDP Egress Partially Meshed Performance Test - Pass/Fail Criteria (Continued) Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors was less than or equal to the value you entered. Fail: The number of frames received with errors was greater than the number you entered.
Test Results
Table 15-4 describes the LDP Egress Partially Meshed Performance test results.
Table 15-4. Result Group OLoad %MaxTxRate AvgTxRunRate AvgRxRunRate TxTput %TxTput AvgLatency Low High DataErrors LDP Egress Partially Meshed Performance Test Results Description Transmit / receive ports comprising a single system under test (SUT). Offered load, the calculated transmit rate in frames per second (f/s). Maximum transmit rate, as a percentage of the theoretical maximum port speed. Measured speed at which the ports transmitted frames. Measured speed at which the ports received frames. Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum throughput. Average latency, in nanoseconds. Number of frames with latencies below the average. Number of frames with latencies above the average. Number of frames received with errors.
15-10

Egress Performance Test
Table 15-4. Result
LDP Egress Partially Meshed Performance Test Results (Continued) Description Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number
SmallSeqError
BigSeqError
Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold.
ReverseSeqError
Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number.
TotalSeqErrors

Overview
This test determines the maximum rate at which an LDP router can strip LDP labels from labeled packets and forward the resulting IP traffic with no loss. To begin the test, a Label Switching Path (LSP) is built either from an Ixia transmit port to a DUT (when the DUT is configured as a Label Edge Router), or from an Ixia port to an Ixia port (when the DUT is configured as a penultimate (PHP) router). Also, an OSPF session is built on the egress DUT ports for packet routing. Using a grid technique, Route Ranges can define large numbers of OSPF routes quickly. If the DUT is configured as an Egress LER, it must forward the traffic out the correct port to another network simulated by the Ixia receive port. If the DUT is configured as a PHP (Penultimate Hop Popping) router, it must strip ('pop') the label from the label packets, and the forward the traffic along the correct LSP to the edge router simulated by the Ixia receive port.
15-11
15

IP test traffic is configured with MPLS labels attached. MPLS traffic is transmitted from the Ixia port to the DUT, which then strips the labels and forwards the traffic out. This test uses a binary search routine to determine the maximum throughput of the DUT. Port mapping for this test is one-to-many, with a minimum of three ports required.
DUT Type = Egress LER standard IP traffic labeled IP traffic
OSPF
CE
Egress Egress DUT Egress LER
LDP
Ingress LER
DUT Type = PHP
standard IP traffic
labeled IP traffic
LDP
Egress LER
OSPF
PHP DUT PHP
LDP
Ingress LER
DUT Type = PHP
Ixia simulated CE
standard IP traffic
Ixia simulated Egress LER
standard IP traffic LSP
Egress LSP Ixia simulated Ingress LER
Labels stripped from traffic LSP Ixia simulated Ingress LER
PHP
Labels stripped from traffic DUT configured as PHP router
DUT configured as Egress LER
Ixia ports
Ixia ports
Figure 15-3. Egress Performance test
The test initially transmits at the rate you specify, which is typically the maximum theoretical rate based on the port speed. If loss occurs, the test uses a binary search algorithm to find a lower rate and re-transmits the traffic. The test continues searching and re-transmitting until it finds a rate at which the DUT does not lose frames. The test results for each frame size are divided into per-port and per-group results: For each port, the results show: Transmit rate in f/s Transmit rate as a percentage of port speed
For each group, the results show:
15-12

Lowest, highest, and average latencies Data errors (bad CRC, etc.) Number of small, large, reverse, and total Sequence Errors
Test Parameters

Table 15-5. Parameter Duration LDP Egress Performance Test Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Max Rate The maximum rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. MPLS Label TTL Extra Inner Labels Time-to-Live value of the MPLS label. Number of labels in the stack below the label used for routing across the network. Multiple labels can be used in service provider networks which have tunnels that reach from one edge router (PE) to another. If the tunnels carry traffic from different VPNs, the outer label identifies the LSP between the edge routers, and the inner label identifies the specific VPN. This parameter is only available when you set DUT Type to PHP.
No. of Trials
Loss Tolerance
Calibrate Latency
15-13
15

LDP Egress Performance Test Parameters (Continued) Description Value of the first label inserted below the LSP routing label. To assign values to the second and subsequent labels, the test increments the value for First Inner Label. For example, if: First Inner Label = 100 and Number of Inner Labels = 3 the test inserts 3 consecutively-numbered labels below the LSP routing label. The first label inserted has the value 100, the next- lower label, 101, and the next, 102. This parameter is only available when you set DUT Type to PHP.
First Inner Label
Binary Search
Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the algorithm searches each port pair separately. A rate change on one port does not affect the others. If you set this field to Linear, the algorithm searches all port pairs together, as a group. A rate change applies to all port pairs.
DUT Type
DUTs function and logical position on the LSP within the test network. PHP: If you select PHP, the test sends traffic to the DUT that includes a label whose value is 0 (IPv4 explicit null). Egress LER: If you select Egress LER the test sends traffic to the DUT that includes a label whose value is 3 (IPv4 implicit null).
OSPF Parameters Network Range Size of simulated network. The test multiplies the values you enter for Rows and Column to create a matrix of simulated nodes. Rows: Number of rows in the matrix Columns: Number of columns in the matrix Number of Subnets Area ID Number of subnets in the simulated matrix of nodes. This value is calculated automatically by the test. The area ID associated with the simulated OSPF interfaces on the Ixia ports. The DUT must belong to the same area.
15-14

LDP Egress Performance Test Parameters (Continued) Description Specify the OSPF network type that you want to simulate: If you are using a POS load module, select Point-topoint. If you are using an Ethernet load module, select Broadcast.
Advertise Delay per Subnet Label Wait Time per Port
Enter the number of seconds per subnet that the test waits before advertising the routes to the DUT. Value used to calculate how long the test waits for labels. The test multiplies the value you enter by the number of transmit ports to calculate the wait time. If the wait time expires before the test receives all the labels, the test stops. Length of time before the test begins transmitting. This delay allows the DUT to finish LDP setup at the beginning of the test. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously.
DUT Processing Delay
Staggered Transmit
Pass/Fail Criteria

Table 15-6. Parameter Pass Criteria LDP Egress Performance Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
15-15
15

LDP Egress Performance Test - Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Sequence Errors
The number of frames received with sequence errors. You can select either of two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was less than or equal to the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered.
15-16

LDP Egress Performance Test - Pass/Fail Criteria (Continued) Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the number of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors was less than or equal to the value you entered. Fail: The number of frames received with errors was greater than the number you entered.
Test Results
Table 15-7 describes the LDP Egress Performance test results.

Table 15-7. Result Group OLoad %MaxTxRate AvgTxRunRate AvgRxRunRate TxTput %TxTput AvgLatency Low High DataErrors LDP Egress Performance Test Results Description Transmit / receive ports comprising a single system under test (SUT). Offered load, the calculated transmit rate in frames per second (f/s). Maximum transmit rate, as a percentage of the theoretical maximum port speed. Measured speed at which the ports transmitted frames. Measured speed at which the ports received frames. Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum throughput. Average latency, in nanoseconds. Number of frames with latencies below the average. Number of frames with latencies above the average. Number of frames received with errors.
15-17
15

Ingress Partially Meshed Performance Test
Table 15-7. Result
LDP Egress Performance Test Results (Continued) Description Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number
SmallSeqError
BigSeqError
Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold.
ReverseSeqError
Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number.
TotalSeqErrors

Overview
This test determines the throughput of an LDP router configured as an ingress node. It is similar to the Ingress Performance Test on page 15-24, except that it allows you to use a partial-mesh port configuration (transmit ports transmit to the same receive ports) and does not perform a binary search to find the maximum no-loss rate. To begin the test, a Label Switching Path (LSP) is built from Ixias receive port to the DUT. Also, an OSPF session is built on the ingress DUT port for packet routing. Using a grid technique, Route Ranges can define large numbers of OSPF routes quickly. IP test traffic is configured with MPLS labels attached.
15-18

Standard IP traffic is transmitted from the Ixia port to the DUT, which then applies the labels and forwards the traffic out. Traffic is transmitted at a predefined rate, along with a step value to iterate the test. Port mapping for this test is partially meshed, meaning that transmit ports transmit traffic to the same receive ports in a many-to-many fashion.
DUT Type = Ingress LER standard IP traffic
labeled IP traffic
OSPF CE
Ingress DUT
LDP OSPF Egress LER
DUT Type = Ingress LER
Simulated CE
standard IP traffic
Ingress LSP Simulated Egress LER
Labels applied to traffic
DUT configured as Ingress LER
Ixia ports
Figure 15-4. Ingress Partially Meshed Performance Test
The test initially transmits at the rate you specify. If the packet loss is within the loss tolerance, the test retransmits at a higher rate. The test continues transmitting at progressively higher rates until the packet loss exceeds the Loss Tolerance, at which point the test ends and prints the results. The test results for each frame size are divided into per-port and per-group results. For each port, the results show: Transmit rate in f/s Transmit rate as a percentage of port speed
For each group, the results show: Lowest, highest, and average latencies Data errors (bad CRC, and so on) Number of small, large, reverse, and total Sequence Errors
The results for all trials include:
15-19
15

Average transmit rate, in f/s Average transmit rate as a percentage of port speed
Test Parameters

Table 15-8. Parameter Duration LDP Ingress Partially Meshed Performance Test Parameters Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Init. Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. Amount added to Init. Rate at the start of each new iteration. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. OSPF Parameters Network Range Size of simulated network. The test multiplies the values you enter for Rows and Column to create a matrix of simulated nodes. Rows: Number of rows in the matrix Columns: Number of columns in the matrix Number of Subnets Area ID Number of subnets in the simulated matrix of nodes. This value is calculated automatically by the test. The area ID associated with the simulated OSPF interfaces on the Ixia ports. The DUT must belong to the same area.
No. of Trials
Loss Tolerance
15-20

LDP Ingress Partially Meshed Performance Test Parameters (Continued) Description Specify the OSPF network type that you want to simulate: If you are using a POS load module, select Point-topoint. If you are using an Ethernet load module, select Broadcast.
Advertise Delay per Subnet DUT Processing Delay
Enter the number of seconds per subnet that the test waits before advertising the routes to the DUT. Length of time before the test begins transmitting. This delay allows the DUT to finish LDP setup at the beginning of the test. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously.
Staggered Transmit
Pass/Fail Criteria

Table 15-9. Parameter Pass Criteria LDP Ingress Partially Meshed Performance Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
15-21
15

LDP Ingress Partially Meshed Performance Test - Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Sequence Errors
The number of frames received with sequence errors. You can select either of two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was less than or equal to the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered.
15-22

LDP Ingress Partially Meshed Performance Test - Pass/Fail Criteria (Continued) Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors was less than or equal to the value you entered. Fail: The number of frames received with errors was greater than the number you entered.
15-23
15

Test Results
Table 15-10 describes the LDP Ingress Partially Meshed Performance test results.
Table 15-10. LDP Ingress Partially Meshed Performance Test Results Result Group OLoad %MaxTxRate AvgTxRunRate AvgRxRunRate TxTput %TxTput AvgLatency Low High DataErrors SmallSeqError Description Transmit / receive ports comprising a single system under test (SUT). Offered load, the calculated transmit rate in frames per second (f/s). Maximum transmit rate, as a percentage of the theoretical maximum port speed. Measured speed at which the ports transmitted frames. Measured speed at which the ports received frames. Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum throughput. Average latency, in nanoseconds. Number of frames with latencies below the average. Number of frames with latencies above the average. Number of frames received with errors. Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.
15-24

Ingress Performance Test

Overview
This test determines the maximum rate at which an LDP router can apply LDP labels to IP traffic and forward the labeled traffic with no loss. To begin the test, a Label Switching Path (LSP) is built from Ixias receive port to the DUT. Also, an OSPF session is built on the ingress DUT port for packet routing. Using a grid technique, Route Ranges can define large numbers of OSPF routes quickly. IP test traffic is configured with MPLS labels attached. Standard IP traffic is transmitted from the Ixia port into the DUT, which then applies the labels and forwards the traffic out. This test uses a binary search routine to determine the maximum throughput of the DUT. Port mapping for this test is one-to-many, with a minimum of three ports required. The test initially transmits at the rate you specify, which is typically the maximum theoretical rate based on the port speed. If loss occurs, the test uses a binary search algorithm to find a lower rate and re-transmits the traffic. The test continues searching and re-transmitting until it finds a rate at which the DUT does not lose frames.
15-25
15

DUT Type = Ingress LER standard IP traffic
labeled IP traffic
OSPF CE
Ingress DUT
LDP OSPF Egress LER
DUT Type = Ingress LER
Simulated CE
standard IP traffic
Ingress LSP Simulated Egress LER
Labels applied to traffic
DUT configured as Ingress LER
Ixia ports
Figure 15-5. LDP Ingress Performance Test
The test results for each frame size are divided into per-port and per-group results. For each port, the results show: Transmit rate in f/s Transmit rate as a percentage of port speed
For each group, the results show: Lowest, highest, and average latencies Data errors (bad CRC, etc.) Number of small, large, reverse, and total Sequence Errors
Test Parameters
15-26

Table 15-11. LDP Ingress Test Parameters Parameter Duration Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Max Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. Determines how the binary search algorithm searches for a new rate. If you set this field to Per-Port, the algorithm searches each port pair separately. A rate change on one port does not affect the others. If you set this field to Linear, the algorithm searches all port pairs together, as a group. A rate change applies to all port pairs. Calibrate Latency If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. OSPF Parameters Network Range Size of simulated network. The test multiplies the values you enter for Rows and Column to create a matrix of simulated nodes. Rows: Number of rows in the matrix Columns: Number of columns in the matrix Number of Subnets Area ID Number of subnets in the simulated matrix of nodes. This value is calculated automatically by the test. The area ID associated with the simulated OSPF interfaces on the Ixia ports. The DUT must belong to the same area.
No. of Trials
Loss Tolerance
Binary Search
15-27
15

Table 15-11. LDP Ingress Test Parameters (Continued) Parameter Interface Network Type Description Specify the OSPF network type that you want to simulate: If you are using a POS load module, select Point-topoint. If you are using an Ethernet load module, select Broadcast. Advertise Delay per Subnet DUT Processing Delay Enter the number of seconds per subnet that the test waits before advertising the routes to the DUT. Length of time before the test begins transmitting. This delay allows the DUT to finish LDP setup at the beginning of the test. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously.
Staggered Transmit
Pass/Fail Criteria

Table 15-12. LDP Ingress Performance Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
15-28

Table 15-12. LDP Ingress Performance Test - Pass/Fail Criteria (Continued) Parameter Load Rate Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified. Sequence Errors The number of frames received with sequence errors. You can select either of two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was less than or equal to the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered.
15-29
15

Table 15-12. LDP Ingress Performance Test - Pass/Fail Criteria (Continued) Parameter Data Errors Description The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors was less than or equal to the value you entered. Fail: The number of frames received with errors was greater than the number you entered.
Test Results
Table 15-13 describes the LDP Ingress Performance test results.

Table 15-13. LDP Ingress Performance Test Results Result Group OLoad %MaxTxRate AvgTxRunRate AvgRxRunRate TxTput %TxTput AvgLatency Low High DataErrors Description Transmit / receive ports comprising a single system under test (SUT). Offered load, the calculated transmit rate in frames per second (f/s). Maximum transmit rate, as a percentage of the theoretical maximum port speed. Measured speed at which the ports transmitted frames. Measured speed at which the ports received frames. Transmit throughput, in frames per second (f/s) Transmit throughput, as a percentage of the theoretical maximum throughput. Average latency, in nanoseconds. Number of frames with latencies below the average. Number of frames with latencies above the average. Number of frames received with errors.
15-30

Transit Performance Test
Table 15-13. LDP Ingress Performance Test Results (Continued) Result SmallSeqError Description Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.

Overview
This test determines the maximum rate at which a label-switching router can receive packets, swap their labels, and forward them with no loss. The DUT is configured as a Transit LSR. The Ixia ports simulate label edge routers (LERs) on either side of the LSR/DUT. A single LSP runs between the edge routers and through the transit router. The test transmit traffic in both directions. The test begins transmitting at the rate you specify for the initial rate. If no packet loss occurs, it re-transmits at increasingly higher rates until packet loss occurs, and the test stops. A many-to-many port mapping is used.
15-31
15

LSP
LDP traf f ic with label 2 LDP traf f ic with label 1 Transit DUT
LDP traf f ic with label 1 LDP traf f ic with label 2
Edge Router
Edge Router
LDP domain / OSPF area
LDP traf f ic with label 2 Edge Router LDP traf f ic with label 1
LSP
LDP traf f ic with label 2 Edge Router LDP traf f ic with label 1 Ixia ports
Transit
DUT conf igured as Transit LSR
LSP
Figure 15-6. Transit Performance Test
The test results for each frame size are divided into per-port and per-group results: For each port, the results show: Transmit throughput (f/s) Average transmit run rate Average receive run rate Data errors (bad CRC, etc.)
For each group, the results show: Lowest, highest, and average latencies Number of small, large, reverse, and total Sequence Errors
The results for all trials include: Total number of frames transmitted Total number of frames received Percentage of frames lost
15-32

Test Parameters

Table 15-14. LDP Transit Performance Test Parameters Parameter Duration Description The duration of the test in hours, minutes and seconds. The test uses the Duration value to calculate the number of frames to transmit. The number of trials to be run. It may be necessary to run several trials of the test to verify consistent results. The percentage of transmitted packets which can be lost before packet loss is declared. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = % Init. Rate The initial rate at which the test transmits frames. Enter this value as a percentage of the maximum theoretical frame rate. Amount added to Init. Rate at the start of each new iteration. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. Extra Inner Labels Number of labels in the stack below the label used for routing across the network. Multiple labels can be used in service provider networks which have tunnels that reach from one edge router (PE) to another. If the tunnels carry traffic from different VPNs, the outer label identifies the LSP between the edge routers, and the inner label identifies the specific VPN. This parameter is only available when you set DUT Type to PHP.
No. of Trials
Loss Tolerance
15-33
15

Table 15-14. LDP Transit Performance Test Parameters (Continued) Parameter First Inner Label Description Value of the first label inserted below the LSP routing label. To assign values to the second and subsequent labels, the test increments the value for First Inner Label. For example, if: First Inner Label = 100 and Number of Inner Labels = 3 the test inserts 3 consecutively-numbered labels below the LSP routing label. The first label inserted has the value 100, the next- lower label, 101, and the next, 102. This parameter is only available when you set DUT Type to PHP. MPLS Label TTL OSPF Parameters Area ID The area ID associated with the simulated OSPF interfaces on the Ixia ports. The DUT must belong to the same area. Specify the OSPF network type that you want to simulate: If you are using a POS load module, select Point-topoint. If you are using an Ethernet load module, select Broadcast. Advertise Delay per Port The maximum time, in seconds, to allow the DUT to absorb each route. This time is multiplied by the number of ports used in the test and the result is used as the maximum wait time after all routes have been sent. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you enable Staggered Transmit if your DUT cannot cope with test traffic arriving on all ports simultaneously. Time-to-Live value of the MPLS label.
Staggered Transmit
Pass/Fail Criteria
15-34

Table 15-15. LDP Transit Performance Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
15-35
15

Table 15-15. LDP Transit Performance Test - Pass/Fail Criteria (Continued) Parameter Sequence Errors Description The number of frames received with sequence errors. You can select either of two methods to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with sequence errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with sequence errors was less than or equal to the number you entered. Fail: The number of frames received with sequence errors was greater than the number you entered. Data Errors The number of frames received with errors. You can select either of two methods to calculate the data errors: Average/Port: The test averages the number of frames received with errors over all ports, then it applies the criteria to determine whether a trial passed or failed Maximum Port: The test selects the amount of frames received with errors on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The number of frames received with errors was less than or equal to the value you entered. Fail: The number of frames received with errors was greater than the number you entered.
Test Results
Table 15-16 describes the LDP Transit Performance test results.

Table 15-16. LDP Transit Performance Test Results Result Group TxTput AvgTxRunRate AvgRxRunRate DataErrors AvgLatency Description Transmit / receive ports comprising a single system under test (SUT). Transmit throughput, in frames per second (f/s) Measured speed at which the ports transmitted frames. Measured speed at which the ports received frames. Number of frames received with errors. Average latency, in nanoseconds.
15-36

Table 15-16. LDP Transit Performance Test Results (Continued) Result Low High SmallSeqError Description Number of frames with latencies below the average. Number of frames with latencies above the average. Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by software) and not negative, OR when the expected sequence number is equal to the previous sequence number BigSeqError Number of packets received with large sequence errors. A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. ReverseSeqError Number of packets received with reverse sequence errors. A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. TotalSeqErrors Combined total of packets with sequence errors of all types.
15-37
16
Chapter 16:
Resource Reservation Protocol (RSVP) Test Suite

Overview of the Resource Reservation (RSVP) Test Suite on page 16-1. Setting Up the Tests on page 16-3.
Table 16-1 lists the IxAutomate RSVP tests.

Table 16-1. Test Label Capacity Test LSP Cutover Test RSVP Tests Description Determines the number of MPLS labels that a labelswitching RSVP router can assign. Finds how long it takes the DUT to switch to new a path after a simulated failure.
Overview of the Resource Reservation (RSVP) Test Suite

RSVP is a QoS signaling protocol used on the Internet for reserving resources (bandwidth) for information of particular types. 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 label switching routers while at the same time reserving necessary bandwidth. RSVP-TE operates in conjunction with other protocols, most notably MultiProtocol Label Switching (MPLS). MPLS in turn depends on the use of a routing protocol, such as OSPF. The most significant output from an RSVP-TE setup session is a set of labels, which are used by the MPLS routers along the path in order to efficiently route network traffic. The operation of RSVP-TE is shown in Figure 16-1.
16-1
16

Overview of the Resource Reservation (RSVP) Test Suite
Sender Routers
Tunnel 1
LSPs 1, 2, 3
Destination Routers
LSRs
Tunnel 2
LSRs
LSR I A
LSR II 1 LSPs 1, 2, 3
PATH Messages
C
RESV Messages
Figure 16-1. RSVP-TE Overview
The RSVP-TE protocol is used to establish paths through MPLS Label Switching Routers (LSRs). In Figure 16-1, Label Switched Paths (LSPs) are created between Sending Routers (A - D) and a set of Destination Routers (1 - 3). The sender routers are referred to as Ingress Routers because they are the entrance points into the set of LSRs, while the destination routers are referred to as Egress Routers because they are the exit points from the LSRs. The path from the ingress router to the egress router is called a Label Switched Path (LSP). Individual flows can travel over one LSP; each of these is called an LSP Tunnel. In Figure 16-1 on page 16-2, LSP tunnels are constructed between Sender Router A and Destination Router 1. Two LSPs (LSP1 and LSP2) are constructed for the traffic, and each carries three distinct tunnels. In actual operation, a sender LSR may establish any number of tunnels carried by any number of LSPs directed at any destination router. 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. 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.
The most significant information passed in the RESV messages sent is a set of labels. At each ingress point of the network, an edge router known as Label Edge Router (LER) examines the IP header to determine which the LSP an incoming packet should use. The LER then encapsulates the packet with MPLS header containing the label information, and forwards the packet to the next hop.
16-2


Most of the RSVP test parameters are common to both tests, and work the same way on both tests. The description of each test includes a description of the Run parameters for that test. The other parameters are common to other IxAutomate tests and described elsewhere: Protocols: All the RSVP tests use IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Frame Sizes: The LSP Cutover test requires you to define the frame size of the background IP traffic. For information on frame sizes, see Choosing Frame Sizes on page 3-45. Learning Frames: see Configuring Learning Frames on page 3-23. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. DUT Setup on page 16-3.
DUT Setup
Table 16-2 lists the Cisco IOS commands necessary to set up a Cisco router to run the RSVP tests. Table 16-3 lists the equivalent commands for a Juniper Networks router.
For a test that uses the DUT as an egress LER, you only need to configure one port. For a test that uses the DUT as a Transit LSR, you must configure two ports. The keys to making tunnels work on a Cisco device with the RSVP tests are: Configuring a loopback interface with a 32-bit subnet mask. The loopback interface is used as the IP address of the tunnel interfaces. This loopback address must be reachable through the DUTs global routing table. Creating a tunnel whose destination is the Destination Router ID in the test setup. Enabling IP unnumbered and assigning unnumbered IP to the loopback interface. The tunnel uses the Loopback interfaces address as its source address.
Cisco Setup Procedure

Global Configuration 1. Configure the lower-layer network protocols on the DUT and check communications between it and the Ixia ports. 2. Enable IP unnumbered and assign unnumbered IP to the loopback interface (replace N with the loopback interfaces ID):
16-3
16

ip unnumbered loopbackN
3. Enable MPLS TE. In General Configuration mode, enter:

ip cef
or, (if available, for greater performance):

ip cef distributed
4. Enable MPLS globally:

mpls traffic-engineering tunnel
5. Enable tag-switching:
tag-switching ip
Interface Configuration On each of the virtual and physical interfaces you can use: 1. Enable MPLS TE tunnels:
mpls traffic-engineering tunnel
2. Enable RSVP and reserve some bandwidth:

ip rsvp bandwidth 1000
3. Set up the tunnels to be used for TE.

tunnel mode mpls traffic-eng
4. Optionally, configure the routing protocol to announce the presence of the tunnel:
tunnel mpls traffic-eng autoroute announce
5. Configure the tunnel to use the loopback interface as its IP address (replace N with the loopback interfaces ID):
tunnel destination loopbackN
Protocol Configuration Configure one of the link-state routing protocols (IS-IS or OSPF) on the DUT to use the loopback interface as the router ID. In Routing Protocol configuration mode, enter the following commands (replace N with the loopback interfaces ID): For IS-IS:
metric-style [wide | both] mpls traffic-eng router-id loopbackN mpls traffic-eng [level-1 | level-2 |]
For OSPF:
mpls traffic-eng area X mpls traffic-eng router-id loopbackN (must have a
255.255.255.255 mask)
16-4

Reviewing the Configuration To review your configuration, use the following commands:
show ip ospf mpls traffic-eng link provides detailed information
about the links over which traffic engineering is supported on the local router.
show ip ospf database opaque-area displays information related to
traffic engineering opaque link-state advertisements (LSAs).

show mpls traffic-eng tunnels verifies the existence and state of the
tunnels.
Table 16-2. Summary of Cisco IOS commands for RSVP tests Description
Command String Global Commands: ip cef mpls traffic-eng tunnels ip unnumbered loopback 0 Port Commands: interface FastEthernet0/0 ip address 198.18.10.1 255.255.255.0 mpls traffic-eng tunnels tag-switching ip ip rsvp bandwidth 1000
Enables Cisco Express Forwarding (CEF) MPLS requires CEF switching. Enables the MPLS traffic engineering tunnel feature on the device. Enables IP unnumbered and assigns it to loopback interface 0.
Assigns an IP address and subnet mask to the port.
Enables the MPLS traffic engineering tunnel feature on the port. Enables tag-switching for IP traffic. (Optional) Enables RSVP for IP on an interface and reserves 1000Kb of bandwidth.
16-5
16

Label Capacity Test
Table 16-3.
Juniper Commands for RSVP Tests Description
Command String [edit interfaces] lo0 { unit 0 { family inet { address 20.1.0.0/32 [edit protocols] protocols { rsvp { interface all; } mpls { label-switched-path to20.1 to 20.1.0.0; interface all; } [edit protocols mpls] edit mpls set traffic-engineering bgp-igp
Configures address 20.1.0.0 on loopback interface lo0.
Enables RSVP on all interfaces. Enables MPLS on all interfaces and creates a dynamic LSP to the egress router at address 20.1.0.0 (the loopback interface).
Configure MPLS to perform traffic engineering on both BGP and IGP destinations.
[edit protocols ospf] set protocols ospf traffic-engineering [edit] set interface so-0/0/0 family mpls
Enable OSPF's traffic engineering features.
Configures SONET interface so-0/0/0 to be part of the MPLS protocol family. Configure each interface you use in the test to belong to the MPLS protocol family.
Label Capacity Test

This section covers the following topics: Overview on page 16-7. Traffic Map on page 16-8. Test Cycle on page 16-8. Test Setup: Run Parameters on page 16-9. Test Setup: Other Parameters on page 16-9. Pass Criteria on page 16-9. Test Results on page 16-10.
16-6

Label Capacity Test
Overview
This test determines the number of Label Switched Path (LSP) or Tunnel Path labels that a label-switching RSVP router can assign. It uses a combination of multiprotocol label switching (MPLS) forwarding and RSVP signaling. The Label Capacity test can test a router in two simulated positions within an RSVP network topology: as a Transit LSR as an Egress LER
As a Transit LSR, the DUT is configured as a label-switching router between an ingress LER and an egress LER. The Ixia ports simulate the ingress and egress LERs. Figure 16-2 and Figure 16-3 show the logical and physical configuration of these tests.
LSP
PATH Ingress Ingress LER RESV Transit Transit LSR (DUT) Tunnel MPLS dom ain
PATH RESV Egress Egress LER
Sim ulated Ingress LER
RESV labels PATH requests DUT configured as Transit LSR
Transit PATH requests RESV labels
Sim ulated Egress LER
Ixia ports
Figure 16-2. Transit LSR Test Scenario
As an Egress LER, the router is configured as the point of egress from an MPLS domain.
16-7
16

Label Capacity Test
Tunnels PATH Ingress Ingress LER LSP RESV Egress Egress LER
MPLS domain IP Addressing: Gateway/DUT PATH request Port simulating Ingress LER IP Addressing: Source Address of First Port RESV labels Egress DUT configured as Egress LER
Figure 16-3. Egress LER Test Scenario
Traffic Map
This test uses different traffic maps depending on whether you test the DUT as a Transit LSR or Egress LER: If you test the DUT as a Transit LSR, the test uses a one-to-one map. If you test the DUT as an Egress LER, the test uses a special type of map which maps the port to itself.
Test Cycle
The test begins by multiplying the values for the NO. OF LSP and TUNNELS parameters. The result is the quantity of labels the test is to request from the DUT. The test requests the labels, then waits for WAIT TIME to elapse. After WAIT TIME elapses, the test collects the labels. If the DUT was able to provide the requested quantity of labels, the test increases the quantity by the amount defined by STEP, and requests the new, larger quantity of labels. It again waits for WAIT TIME to elapse before collecting the labels. While the test runs, it monitors the number of labels it has received. The test continues to request increasing numbers of labels as long as it keeps receiving increasing numbers of labels (within the failure threshold set by TOLERANCE). Eventually, one of the following conditions occurs: the number of received labels decreases (from the highest received number during the polling period) the number of labels is zero (never exceeds zero from the start of the test) the number of received labels is equal to the previously received number
16-8

Label Capacity Test
When one of these conditions occurs, the test checks three times that the condition is persistent. WAIT TIME defines the interval between each check. If the condition does not persist, the test continues as before, requesting increasing numbers of labels. If the condition does persist through all three polls, the test ends and reports the best results for that trial.
Table 16-4. Parameter No. of Trials Tolerance
RSVP Label Capacity Test Run Parameters Description Select the number of times you want the test to run. Enter the percent loss tolerance. For example, if you enter 5, the test allows the DUT to lose 5% of the route prefixes without judging it to have failed. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Wait Time DUT Type LSP / Tunnel
This parameter controls how long the test waits before collecting the label statistics. Specify the DUTs position in the simulated network. See Figure 16-2 on page 16-7 and Figure 16-3 on page 16-8. This parameter enables you to vary the ratio of tunnels to LSPs. You specify either the number of tunnels or of LSPs, and the test fixes the other parameter at its default value.
Number Step Generate ERO
Specify the number of labels the test initially requests. Specify the additional number of labels that test adds to Number for the next request. If you check this box, the test includes an Explicit Route Object (ERO) in the PATH message sent to the egress router. The ERO contains the addresses of the DUT ingress and the egress ports. This option is only available if the DUT Type is Transit LSR.
Traffic Map: See Setting Up the Traffic Map on page 3-11. Protocol: See Configuring IP Addresses on page 3-25 for information. Using
the default values for these fields, the receive port addresses are 198.18.2.2 and 198.18.3.2. Ensure that the corresponding ports on the DUT are on the same networks as the receive ports.
Pass Criteria
Table 16-5 lists the pass criteria for this test:
16-9
16

Label Capacity Test
RSVP Label Capacity Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The percentage of labels sent that can be lost. You can select either of two methods to calculate the percentage of label lost: Average/Port: The test averages the label loss over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the maximum label loss experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The percentage of labels lost is less than or equal to the number you entered. Fail: The percentage of labels lost is larger than the number you entered.
Pass Criteria
%Label Loss
Test Results
The test displays the best results for each trial including: number of labels received per port expected number of labels aggregate total of labels received on all ports percent loss configured tolerance value (if it is greater than zero)
Note: If you stop a test while the RSVP and OSPF services are running and then try to re-run it or run the other RSVP test, the test fails. To ensure that the RSVP and OSPF services have stopped: 1. Start IxExplorer. 2. Click the plus symbol (+) next to the card used in the test to display its ports. 3. Double-click the port used in the test to display the various windows available for it. 4. Double-click the Protocol Window to display the list of protocols. 5. From the list of protocols displayed, double-click RSVP to display the ports that have RSVP enabled. 6. Select the port used in your test, and click Stop RSVP 7. From the list of protocols displayed, double-click OSPF to display the ports that have OSPF enabled. 8. Select the port used in your test, and click Stop OSPF 9. Repeat steps 2 - 8 for any additional ports used in your test.
16-10

LSP Cutover Test
LSP Cutover Test

This section covers the following topics: Overview on page 16-11. Choosing the Lowest-cost Route on page 16-11. Test Cycle on page 16-12. Test Setup: Run Parameters on page 16-13. Test Setup: Other Parameters on page 16-13. Pass Criteria on page 16-13. Test Results on page 16-14.
Overview
This determines how long it takes the DUT to switch to a new path after a simulated failure on a link. It transmits traffic from a simulated network across the DUT, and forces the DUT to change paths following the link failure. The test allows you to simulate a physical port failure or a software failure in the OSPF protocol, and determine how long it takes the DUT to react and switch to the new path. This test requires one transmit port and two receive ports. Both receive ports must be of the same media type. A one-to-many port mapping is used. The test creates an OSPF area and assigns to it the two receive ports. The transmit port simulates an external router that is the origin of the traffic. The receive ports simulate egress LERs for the OSPF area. The DUT must be configured as the ingress LER to that area. Internally, the Ixia card simulates a network that is the destination of the traffic. The DUT, as the ingress LER, has one link to the origin (the transmit port), and links to two egress LERs (the receive ports). The egress LERs both have connections to the same (simulated) network, which is the destination of the traffic. The DUT receives the incoming traffic (from the transmit port), and must decide how to route it through the egress LERs (the two receive ports) to its destination (the simulated network). Because both the egress LERs have paths to the simulated network, two paths are available. One of the paths has a lower cost metric than the other. While both paths are available, the DUT should send the traffic over the lower-cost path. When the test triggers the failure on the lower-cost path, the DUT should re-route the traffic over the higher-cost path. This test determines how long it takes the DUT to re-route the traffic. Figure 16-4 on page 16-12 displays the logical and physical configuration of this test.
Choosing the Lowest-cost Route
The test assigns the lowest cost to the route with the lowest-numbered receive port. For example, if you create a traffic map by adding the following ports in the following order:
16-11
16

LSP Cutover Test
1,1,1 --> 1,1,4 1,1,1 --> 1,1,2
the test assigns the lowest cost to the route to 1,1,2.
OSPF area low-cost path Egress egress LER
Ingress network (traffic origin) ingress LER
high-cost path Egress egress LER
network (traffic destination)
IP Addressing: Router ID Transmit port simulating network (traffic origin) IP Addressing: Source Address of First Port Ingress low-cost path receive ports as egress LERs to traffic destination Destination network simulated by Ixia card IP Addressing: Destination Router ID Destination IP Address high-cost path DUT configured as ingress LER
OSPF area
Figure 16-4. LSP Label Cutover Test Scenario
Test Cycle
The test begins by starting OSPF and RSVP on the receive ports. As the OSPF topology goes into Full state, the DUT sets up a path to the Ixia receive port that advertised the routes with the lowest cost metric. When the DUT has set up the LSP, the transmit port begins transmitting traffic. The DUT should route the traffic over the link with the lowest cost metric. When the first flap interval has elapsed, the test triggers the selected failure on the preferred (lower-cost) link. To calculate the timing of the flaps, the test divides DURATION by NO. OF FLAPS + 1:
Duration / (No. of Flaps + 1) = Flap Interval
When the DUT detects the failure, it should calculate a new path over the remaining link and redirect the traffic over it. The flap can be either a link failure or a change in the OSPF topology. If the flap type is a link failure, each flap causes the link to go down (if it is up) or up (if a previous flap took it down). If you specify more than one flap, the link comes up or goes down the specified number of times, at the calculated intervals.
16-12

LSP Cutover Test
RSVP LSP Cutover Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. Select the number of times you want to run the test. Sets the frame rate of the background IP traffic. Specify the frame rate in terms of a percentage of the DUTs maximum port speed. Enter the OSPF area ID configured on the DUT. Specify the OSPF network type that you want to simulate: If you are using a POS load module, select point-topoint. If you are using an Ethernet load module, select broadcast
No. of Trials Max Rate
Area ID Interface Network Type
DUT Router ID Destination Router ID No. of Flaps
Specify the DUTs Loopback address. Specify the tunnel address. Specify the number of simulated failures to occur during the test. A flap is either a withdrawal of a route, or a re-advertising of a withdrawn route. Specify the type of failure you want to simulate: hardLink simulates a physical port failure by placing the port in loopback mode. ospfFlap simulates a software failure in the OSPF protocol by disabling the User LSAs.
Flap Type
Protocol: See Configuring IP Addresses on page 3-25. Frame Size: Specify the frame sizes of the background IP traffic. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Learning Frames: See Configuring Learning Frames on page 3-23. Traffic Map: See Setting Up the Traffic Map on page 3-11. Ensure that the
two ports you select to be the receive ports are of the same media type.
Pass Criteria

Table 16-7. Parameter Pass Criteria RSVP LSP Cutover Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
16-13
16

LSP Cutover Test
RSVP LSP Cutover Test - Pass Criteria Description The numerical threshold value for convergence metric time. Specify the value, in seconds (s). Pass: The convergence time was less than or equal to the number you entered. Fail: The convergence time was greater than the number you entered.
Convergence Metric
Test Results
While the DUT is switching the traffic to the remaining link, the transmit port continues transmitting. Because the DUT takes some time to switch the traffic, some packets continue to travel over the downed link, and others are lost inside the DUT. Because the original path is another Ixia receive port, the test can count the number that arrive after the link failure. The test subtracts the number sent over the original link after the failure from the total of all packets received. The result is the number of packets lost inside the DUT. The test then divides the number of packets lost by the transmit rate, and the result is the time the DUT required to switch to the remaining link. The test calculates the how long the DUT took to switch to a new path based on the frame rate and the number of packets lost when the link went down.
Note: If you stop a test while the RSVP and OSPF services are running and then try to re-run it or run the other RSVP test, the test fails. To ensure that the RSVP and OSPF services have stopped: 1. Start IxExplorer. 2. Click the plus symbol (+) next to the card used in the test to display its ports. 3. Double-click the port used in the test to display the various windows available for it. 4. Double-click the Protocol Window to display the list of protocols. 5. From the list of protocols displayed, double-click RSVP to display the ports that have RSVP enabled. 6. Select the port used in your test, and click Stop RSVP 7. From the list of protocols displayed, double-click OSPF to display the ports that have OSPF enabled. 8. Select the port used in your test, and click Stop OSPF 9. Repeat steps 2 - 8 for any additional ports used in your test.
16-14
17
Chapter 17:
OSPF Test Suite
This chapter covers the following topics: Setting Up the Tests on page 17-1.
IxAutomate includes the following tests for the OSPF protocol: OSPF Convergence Test on page 17-3 tests the ability of an OSPF router to switch between preferred and less-preferred routes when the preferred routes are withdrawn and re-advertised. This test differs from the OSPF Route Convergence Test in that it supports OSPF version 2 and version 3, it allows you to specify which Link State Advertisements (LSAs) are advertised and withdrawn, and it uses a different method to determine convergence time. OSPF Route Capacity Test on page 17-11 determines the number of routes that an OSPF router can sustain. OSPF Route Convergence Test on page 17-16 tests the ability of an OSPF router to switch between preferred and less-preferred routes when the preferred routes are withdrawn and re-advertised. OSPF Performance Test on page 17-22 determines the throughput and latency of the DUT when forwarding traffic based on the OSPF routing table.

Most OSPF test parameters are common to all the tests, and work the same way on all of them. The description of each test includes a description of the Run parameters for that test. The other parameters are described as follows: Protocols: All OSPF tests use IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Frame Sizes: All OSPF tests require you to define the frame size of the IP traffic that the test uses to test the DUT OSPF routing. For information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. DUT Setup on page 17-2.
17-1
17
OSPF Test Suite

DUT Setup
To configure the DUT for the OSPF tests, use its management software to: configure an IP address on the interfaces (ports) you can use enable OSPF assign the ports to an OSPF area
Sample Commands
Table 17-1 lists the basic Cisco IOS commands for configuring OSPF on Cisco routers, except for the Catalyst series, which have VLAN interfaces.
Cisco
Table 17-1. Cisco IOS commands for OSPF tests Description
Command String Global Commands: configure terminal Port Commands: interface fastEthernet 0 ip address 10.10.10.1 255.255.255.0 no shutdown exit router ospf 10
Enters global configuration mode from the terminal.
Selects a Fast Ethernet interface for configuration. Applies an IP address and subnet mask to the selected interface. Brings up the interface. Exits global configuration mode. Enters router configuration mode and enables OSPF routing with a process ID of 10.
17-2
OSPF Test Suite

OSPF Convergence Test
Table 17-1.
Cisco IOS commands for OSPF tests (Continued) Description Defines a network that uses OSPF and defines the area ID for that network. Displays the configuration running on the Cache Engine. Review the displayed configuration to make sure that it is correct. Using the correct wildcard mask is the key to running OSPF successfully and enabling the specified subnet. The commands shown in this example enabled any interface on the router that falls within the 10.10.10.0/24 network subnet to participate in OSPF area 0.
Command String network 10.10.10.0 0.0.0.255 area 0 show running-config ! interface FastEthernet0 ip address 10.10.10.1 255.255.255.0 no ip directed-broadcast full-duplex end ! router ospf 10 network 10.10.10.0 0.0.0.255 area 0 !

This section covers the following topics: Overview on page 17-3. Choosing the Lowest-cost Route on page 17-4. Choosing a Value for DUT Processing Delay on page 17-4. Finding a Value for the Max. Rate Parameter on page 17-5. Test Cycle on page 17-5. Supported Protocols on page 17-6. Test Setup: Run Parameters on page 17-7. Test Setup: Other Parameters on page 17-9. Pass Criteria on page 17-9. Test Results on page 17-10. Troubleshooting on page 17-10.
Overview
This test determines the ability of an OSPF router to switch between preferred and less-preferred routes when the preferred routes are withdrawn and re-advertised. This test differs from the OSPF Route Convergence Test in the following ways: It supports OSPF version 2 and version 3 It allows you to specify which Link State Advertisements (LSAs) are advertised and withdrawn
17-3
17
OSPF Test Suite

It does not use packet loss to determine convergence time (although it does report the number of lost packets); instead, it uses a more accurate timestamp approach.
The test implements the test model shown in Figure 17-1 on page 17-4. This test uses three Ixia ports one to transmit and two to receive. Both receive ports must be of the same media type. The traffic mapping is one-to-many, and the transmit direction is unidirectional. You must set up the port map manually; there is no Automatic option for setting up the port map.
Figure 17-1. OSPF Convergence Test
In this test, two Ixia receive (Rx) ports simulate OSPF routers. Both routers advertise the same route prefixes to the simulated network. However, the routes advertised by the preferred port have smaller metrics (lower costs), which should cause the DUT to forward traffic over them instead of the routes advertised by the other port.
Choosing the Lowest-cost Route
The test selects the first transmit/receive port pair in the list to be the lowest-cost (preferred) path. For example, if you create a traffic map by adding the following ports:
1,1,1 --> 1,1,2 1,1,1 --> 1,1,3
the test assigns the lowest cost to the path to 1,1,2. The path to 1,1,3 is the secondary path.
Choosing a Value for DUT Processing Delay
The DUT Processing Delay allows the DUT to finish OSPF setup at the beginning of the test before the test begins transmitting. As a guide for choosing a value for this parameter, if you set this value too low, the test Log window shows many packets being lost.
17-4
OSPF Test Suite

Finding a Value for the Max. Rate Parameter
Although this test does not use packet loss to determine convergence time, it does report the number of packets lost by the DUT. To ensure that any packets that are lost are lost due to route convergence and not to other causes, you should configure a value for MAX RATE that does not cause the DUT to lose packets. If you set a value for MAX RATE that is too high for the DUT, it may lose packets due to throughput limitations instead of route convergence limitations. To workaround this, before you run the OSPF Convergence test to gain actual results, you should run it to find a value for MAX RATE at which the DUT loses no packets. Use the following procedure: 1. Configure the test with all the values you plan to use. 2. Set the NO. OF WITHDRAWALS to zero (0). 3. Start the test. Configuring the test this way makes it behave like a throughput test. The results file display the amount of packet loss on the link. If you receive any packet loss, decrease the MAX RATE.
Test Cycle
The test starts OSPF on the receive ports and sends the selected LSAs to the DUT. The test waits for the time specified by MAX WAIT TIME to acknowledge it has received the LSAs and has reached the OSPF Full state. If MAX WAIT TIME expires before this happens, the test ends. Once the DUT reaches OSPF Full state, the test waits for the time specified by
DUT PROCESSING DELAY to ensure that the DUT has finished its setup and is ready. When DUT PROCESSING DELAY expires, the transmit (Tx) port begins
transmitting validation traffic to addresses in all of the advertised routes. The DUT should forward all the validation traffic over the preferred route (the route with the lower metric). The timing for the route withdrawal is shown in Figure 17-2. To calculate the interval between withdrawing and re-advertising the routes, the test uses the following formula:
Interval = Duration / (No. of Withdrawals * 2)
For example, in Figure 17-2, the value for NO. OF WITHDRAWALS is set to 2.
17-5
17
OSPF Test Suite

Figure 17-2. OSPF Convergence Test Timing
After the interval has elapsed, the receive port simulating the preferred route withdraws its LSAs for a period of time. During that time, the DUT should detect that the preferred route has gone down and switch traffic to the secondary route. When the transmit rate returns to 99% of the Max. Rate, the test checks the timestamps on the validation traffic to determine the convergence time. The router simulating the preferred routes then re-advertises its LSAs. The DUT should again detect the change in topology and re-route traffic onto the preferred path. As before, when the transmit rate returns to 99% of the Max. Rate, the test checks the timestamps on the validation traffic to determine the convergence time. The NO. OF WITHDRAWALS parameter determines how many times the withdrawand-advertise sequence repeats during the test. Each withdraw-and-advertise sequence constitutes one flap. The TRANSMIT DURATION BETWEEN FLAPS parameter determines the minimum amount of time that the test transmits the validation traffic between flaps. The test continues until DURATION has elapsed. If you specified more than one trial, the test waits for the DUT PROCESSING DELAY to expire, causing the DUT to purge its route table. Then, the test starts the next trial using the same frame size. After the trials for that frame size are complete, the test either ends or, if you specified more than one frame size, waits for the DUT PROCESSING DELAY to expire, then restarts with the next larger frame size.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6 Advanced Scheduler Receive port Wide Packet Groups
17-6
OSPF Test Suite

Table 17-2. Parameter No. of Trials Max Rate Area ID
OSPF Convergence Test Run Parameters Description Select the number of times you want the test to run. The rate at which frames are transmitted. This is the percentage of the maximum theoretical frame rate. The area ID associated with the simulated OSPF interface. The DUT must belong to the same area. Specify how many times the test withdraws and readvertises the routes. Delay used in various places throughout the test: After establishing the OSPF sessions, to allow the DUT to settle down and update its routing table. The test does not transmit during this period. Before the first LSA withdrawal. The test transmits during this time. Before and after each flap. Before stopping the OSFP service on the receive ports at the end of the test. Amount of time allowed for the DUT to return to 99% of the Max Rate following an LSA advertisement or withdrawal. The test measures convergence time when throughput reaches 99% of the Max Rate. If it cannot achieve this throughput within the time allowed by the Transmit Timeout, the test ends. Specify the OSPF network type that you want to simulate: If you are using a POS load module, select point-topoint. If you are using an Ethernet load module, select broadcast.
No. of Withdrawals DUT Processing Delay
Transmit Timeout
Transmit Duration Between Flaps
Amount of time that the test uses to transmit the validation traffic. If the results show many dropped packets, increase this parameter to allow your DUT more time to absorb all the validation traffic. If you check this box, the test allows you to specify an MTU size, and then validates the MTU during database exchange with the DUT.
Validate MTU Size
17-7
17
OSPF Test Suite

OSPF Convergence Test Run Parameters (Continued) Description Select the LSAs that the test is to advertise. For each LSA type that you select, specify how many of those LSAs the test is to send by entering a value in the corresponding Number LSA field. If you want the test to withdraw an LSA, check the corresponding Withdraw LSA field. The subnets advertised by the LSAs are as follows: OSPFv2 Summary LSA OSPFv2 External LSA OSPFv2 Router LSA Router ID OSPFv2 Router LSA Subnet OSPFv3 External LSA OSPFv3 Prefix Length OSPFv3 Router LSA Router ID OSPFv3 Router LSA Subnet 10.0.0.0 192.1.0.0 25.0.0.1 17.0.0.0 2004:1240: :0 64 50.0.0.1 2003:EEAA: :0
Traffic Pattern
OSPFv3 Inter-Area Prefix LSA Subnet 2005:1002: :0
Advertise Delay per LSA
The maximum time, in seconds, to allow the router to absorb each LSA. This time is multiplied by the number of LSAs advertised to the router and used as the maximum wait time after all routes have been sent. The length of time the test waits for DUT to absorb route changes. The test calculates this value by multiplying the total number of LSAs advertised by the Advertise Delay per LSA. Select to enable Graceful Restart Helper Mode on the emulated OSPF router per RFC 3623. NOTE: This option is available for OSPFv2 (using the IP protocol) only. In order to select it, at least one OSPFv2 LSA must be enabled in the Traffic Pattern area.
Max Wait Time
Graceful Restart RFC 3623 Support
Strict LSA Checking
Select to enable Strict LSA Checking. The OSPF Restart Helper will terminate Graceful Restart when there are changes to an LSA that would be flooded to, or retransmitted by, the restarting router. Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software restart on the restarting router (a planned or unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software reload or upgrade on the restarting router (a planned outage).
Support Reason Software Restart
Support Reason Software Reload Upgrade
17-8
OSPF Test Suite

OSPF Convergence Test Run Parameters (Continued) Description Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is an unplanned switchover to a redundant control processor on the restarting router (an unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is unknown and unplanned.
Support Reason Switch to Redundant Control Processor
Support Reason Unknown
Frame Size: Specify the sizes of the test frames sent to each destination. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. Also see Choosing
the Lowest-cost Route on page 17-4. Make sure that the two ports you select to be the receive ports are of the same media type.
Protocol: This test supports IPv4 or IPv6. See Configuring IP Addresses on
page 3-25.
Pass Criteria

Table 17-3. Parameter Enable Pass Criteria OSPF Convergence Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The numerical threshold value for average advertise convergence time. Specify this value in terms of nanoseconds (ns). Pass: The average advertise convergence time was less than or equal to the number you entered. Fail: The average advertise convergence time was greater than the number you entered. Avg Withdraw Convergence Time The numerical threshold value for average withdraw convergence time. Specify this value in terms of nanoseconds (ns). Pass: The average withdraw convergence time was less than or equal to the number you entered. Fail: The average withdraw convergence time, was greater than the number you entered.
Avg Advertise Convergence Time
17-9
17
OSPF Test Suite

Test Results
Table 17-4 describes the OSPF Convergence test results.

Table 17-4. Result Packet Loss Convergence Time (Withdrawals) Convergence Time (Advertise) OSPF Convergence Test Results Description Number of packets transmitted but not received Time required for the DUT to re-route traffic from the preferred (lower-cost) path to the secondary (higher-cost) path following withdrawal of the LSAs. Time required for the DUT to re-route traffic from the secondary (higher-cost) path to the path preferred (lower-cost) following re-advertisement of the LSAs.
Troubleshooting
If the Log window displays the following error:

collectPacketGroupStats: Stats not available for packet group <number>
Increase the value for DUT Processing Time. If the test terminates with the following error message:
Port x.x.x: Percent Throughput is 2%, desired percentage is 99% ***** ERROR: Thoughput has not reached desired rate 99% after a period of 100 seconds.
Increase the value for Transmit Timeout.

Note: If you stop a test while the OSPF service is running and then try to re-run it or another OSPF test, the test fails. To ensure that the OSPF service has stopped: 1. Start IxExplorer. 2. Click the plus symbol (+) next to the card used in the test to display its ports. 3. Double-click the port used in the test to display the various windows available for it. 4. Double-click the Protocol Window to display the list of protocols. 5. From the list of protocols displayed, double-click OSPF to display the ports that have OSPF enabled. 6. Select the port used in your test, and click Stop OSPF. 7. Repeat steps 2 - 6 for any additional ports used in your test.
17-10
OSPF Test Suite

OSPF Route Capacity Test

This section covers the following topics: Overview on page 17-11. Choosing a Value for DUT Processing Delay on page 17-11. Test Cycle on page 17-12. Supported Protocols on page 17-12. Test Setup: Run Parameters on page 17-12. Test Setup: Other Parameters on page 17-14. Pass Criteria on page 17-14. Test Results on page 17-14.
Overview
The route capacity test finds the number of routes that an OSPF DUT can sustain. It uses the test model in Figure 17-3. This test uses two Ixia ports one to transmit and one to receive. The traffic mapping is one-to-one, and the transmit direction is unidirectional.
Figure 17-3. OSPF Route Capacity Test Note: You can use only one Ixia transmit port and one Ixia receive port per DUT for the Route Capacity test. If you want to run the Route Capacity test using more than one pair of transmit and receive ports, you must connect each additional pair to additional DUTs.
Choosing a Value for DUT Processing Delay
The DUT Processing Delay allows the DUT to finish OSPF setup at the beginning of the test before the test begins transmitting. As a guide for choosing a value for this parameter, if you set this value too low, the test Log window shows many packets being lost.
17-11
17
OSPF Test Suite

Test Cycle
This test begins with the receive (Rx) port simulating the router advertising the route prefixes of the simulated network. The test waits for the DUT to acknowledge the routes and to go to the OSPF Full state. If the MAX WAIT TIME expires before this happens, the test ends. Once the DUT reaches Full state, the test waits ten seconds to ensure that the DUT has finished its setup and is ready. When the ten seconds have expired, the test sends a single packet, whose size is specified by FRAME SIZE, from the transmit port to an address in each of the advertised route prefixes. If all the transmitted packets are received within the loss TOLERANCE, the test increases the number of advertised route prefixes and repeats. The size of the increase is determined by the ROUTE STEP parameter. The test continues until the DUT fails to handle the advertised number of route prefixes. The test then waits for the DUTs OSPF Dead Interval to expire, causing the DUT to purge its route table. If you specified more than one trial, the test starts the next trial using the same frame size. After the trials for that frame size are complete, the test either ends or, if you specified more than one frame size, restarts with the next larger frame size.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6 Packet Streams Receive port Capture mode
Table 17-5. Parameter No. of Trials Max Rate
OSPF Route Capacity Test Run Parameters Description Select the number of times you want the test to run. The rate at which frames are transmitted. This is the percentage of the maximum theoretical frame rate. Length of time before the test begins transmitting. This delay allows the DUT to finish OSPF setup at the beginning of the test. If you check this box, the test allows you to specify an MTU size, and then validates the MTU during database exchange with the DUT. The number of prefixes to generate at the start of the test.
DUT Processing Delay Validate MTU Size
No. of Routes
17-12
OSPF Test Suite

Table 17-5. Parameter Route Step Tolerance
OSPF Route Capacity Test Run Parameters (Continued) Description The number of prefixes to add to the No. of Routes value on each iteration of the test. Enter the percent loss tolerance. For example, if you enter 5, the test allows the DUT to lose 5% of the route prefixes without judging it to have failed. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Area ID Interface Network Type
The area ID associated with the simulated OSPF interface. The DUT must belong to the same area. Specify the OSPF network type that you want to simulate: If you are using a POS load module, select point-topoint. If you are using an Ethernet load module, select broadcast.
Advertised IP Network The network advertised by the routes. Prefix Length Advertise Delay per Route The length of the prefixes generated for the advertised routes. The maximum time, in seconds, to allow the router to absorb each route. This time is multiplied by the number of routes advertised to the router and used as the maximum wait time after all routes have been sent. The length of time the test waits for DUT to absorb route changes. The test calculates this value by multiplying the Number of Routes by the Advertise Delay per Route. Select to enable Graceful Restart Helper Mode on the emulated OSPF router per RFC 3623. NOTE: This option is available for OSPFv2 (using the IP protocol) only. Strict LSA Checking Select to enable Strict LSA Checking. The OSPF Restart Helper will terminate Graceful Restart when there are changes to an LSA that would be flooded to, or retransmitted by, the restarting router. Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software restart on the restarting router (a planned or unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software reload or upgrade on the restarting router (a planned outage).
Max Wait Time
Support Reason Software Reload Upgrade
17-13
17
OSPF Test Suite

OSPF Route Capacity Test Run Parameters (Continued) Description Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is an unplanned switchover to a redundant control processor on the restarting router (an unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is unknown and unplanned.
Support Reason Switch to Redundant Control Processor
Frame Size: Specify the sizes of the test frames sent to each destination. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. Protocol: This test supports IP protocol only. See Configuring IP Addresses
on page 3-25.
Pass Criteria

Table 17-6. Parameter Pass Criteria OSPF Route Capacity Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The minimum number of routes that the DUT is able to transmit to. Pass: The minimum number of routes verified was equal to or greater than the number you entered. Fail: The minimum number of routes verified was lower than the number you entered.
Min Routes Verified
Test Results
Table 17-7 describes the OSPF Route Capacity test results.

Table 17-7. Result TxFrames OSPF Route Capacity Test Results Description Number of frames transmitted. The test transmits one frame to each route per iteration, so the number of frames transmitted equals the number of routes advertised. Number of frames received. Number of routes configured. Increase in number of routes per iteration. Transmit rate of IP test traffic.
RxFrames Number of Routes Route Step Packet Rate
17-14
OSPF Test Suite

Table 17-7. Result Tolerance Total Loss
OSPF Route Capacity Test Results Description Configured loss tolerance threshold. Percentage of frames lost. To find the total loss, the test divides the number of lost frames by the number of transmitted frames, and then multiplies the result by 100: Total Loss = (Lost frames / Tx frames) * 100
Max. Routes Verified
Maximum number of routes that the DUT was able to transmit to.
17-15
17
OSPF Test Suite

OSPF Route Convergence Test

This section covers the following topics: Overview on page 17-16. Choosing a Value for DUT Processing Delay on page 17-17. Choosing the Lowest-cost Route on page 17-17. Finding a Value for the Max. Rate Parameter on page 17-17. Test Cycle on page 17-17. Supported Protocols on page 17-18. Test Setup: Run Parameters on page 17-18. Test Setup: Other Parameters on page 17-20. Pass Criteria on page 17-20. Test Results on page 17-21. How the Test Calculates the Results on page 17-21.
Overview
The route convergence test tests the ability of a DUT router to switch between preferred and less-preferred routes when the preferred routes are withdrawn and re-advertised. The test implements the test model shown in Figure 17-4 on page 17-16. This test uses three Ixia ports one to transmit and two to receive. Both receive ports must be of the same media type. The traffic mapping is one-tomany, and the transmit direction is unidirectional.
Figure 17-4. OSPF Route Convergence Test
In this test, two Ixia receive (Rx) ports simulate OSPF routers. Both routers advertise the same route prefixes to the simulated network. However, the routes advertised by Router 1 have smaller metrics (lower costs), which causes the DUT to forward traffic over them instead of Router 2 routes.
17-16
OSPF Test Suite

Choosing a Value for DUT Processing Delay Choosing the Lowest-cost Route
The DUT Processing Delay allows the DUT to finish OSPF setup at the beginning of the test before the test begins transmitting. As a guide for choosing a value for this parameter, if you set this value too low, the test Log window shows many packets being lost. The test assigns the lowest cost to the route with the lowest-numbered receive port. For example, if you create a traffic map by adding the following ports in the following order:
1,1,1 --> 1,1,4 1,1,1 --> 1,1,2
the test assigns the lowest cost to the route to 1,1,2.
The accuracy of this test depends on the test assuming that any packets that are lost are lost due to route convergence, not to other causes. If you set a value for MAX RATE that is too high for the DUT, it may lose packets due to throughput limitations instead of route convergence limitations. To workaround this, before you run the Route Convergence test to gain actual results, you should run it to find a value for Max Rate at which the DUT loses no packets. Use the following procedure: 1. Configure the test with all the values you plan to use. 2. Set the NO. OF WITHDRAWALS to zero (0). 3. Start the test. Configuring the test this way makes it behave like a throughput test. The results file displays the amount of packet loss on the link. If you receive any packet loss, decrease the MAX RATE.
Test Cycle
The test waits for the DUT to acknowledge it has received the routes and the DUT to go to the OSPF Full state. If the MAX WAIT TIME expires before this happens, the test ends. Once the DUT reaches OSPF Full state, the test waits ten seconds to ensure that the DUT has finished its setup and is ready. When the ten second delay expires, the transmit (Tx) port begins transmitting a stream of packets to an address in each of the advertised route prefixes. The DUT forwards all the packets over the route with the lower metric (Router 1). The timing for the route withdrawal is shown in Figure 17-5. To calculate the interval between withdrawing and re-advertising the routes, the test uses the following formula:
Interval = Duration / (No. of Withdrawals * 2)
For example, in Figure 17-5, the value for NO. OF WITHDRAWALS is set to 2.
17-17
17
OSPF Test Suite

Figure 17-5. OSPF Route Convergence Test Timing
After the interval has elapsed, the receive port simulating Router 1 withdraws its routes for a period of time. During that time, the DUT should detect that the preferred route has gone down and switch traffic to Router 2s routes. Router 1 subsequently re-advertises its routes. The DUT should again detect a change and reroute traffic to the receive port simulating Router 1. The test continues until the time interval set by the DURATION parameter elapses. If you specified more than one trial, the test waits for the DUTs OSPF Dead Interval to expire, causing the DUT to purge its routing table. Then, the test starts the next trial using the same frame size. After the trials for that frame size are complete, the test either ends or, if you specified more than one frame size, waits for the DUTs OSPF Dead Interval to expire, then restarts with the next larger frame size. A one-to-many port mapping is used with three port minimum.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6 Packet Streams Receive port Capture mode
Table 17-8. Parameter Duration No. of Trials Max Rate
OSPF Route Convergence Test Run Parameters Description Specify how long you want the test to transmit for. Select the number of times you want the test to run. The rate at which frames are transmitted. This is the percentage of the maximum theoretical frame rate.
17-18
OSPF Test Suite

OSPF Route Convergence Test Run Parameters (Continued) Description Length of time before the test begins transmitting. This delay allows the DUT to finish OSPF setup at the beginning of the test. If you check this box, the test allows you to specify an MTU size, and then validates the MTU during database exchange with the DUT. Specify how many times the test withdraws the routes. The number of prefixes to generate at the start of the test. The area ID associated with the simulated OSPF interface. The DUT must belong to the same area. The length of the prefixes generated for the advertised routes. The network associated with the advertised routes. Specify the OSPF network type that you want to simulate: If you are using a POS load module, select point-topoint. If you are using an Ethernet load module, select broadcast.
DUT Processing Delay Validate MTU Size
No. of Withdrawals No. of Routes Area ID Prefix Length Network IP Address Interface Network Type
Advertise Delay per Route
The maximum time, in seconds, to allow the router to absorb each route. This time is multiplied by the number of routes advertised to the router and used as the maximum wait time after all routes have been sent. The length of time the test waits for DUT to absorb route changes. The test calculates this value by multiplying the Number of Routes by the Advertise Delay per Route. Select to enable Graceful Restart Helper Mode on the emulated OSPF router per RFC 3623. NOTE: This option is available for OSPFv2 (using the IP protocol) only.
Max Wait Time
Strict LSA Checking
Select to enable Strict LSA Checking. The OSPF Restart Helper will terminate Graceful Restart when there are changes to an LSA that would be flooded to, or retransmitted by, the restarting router. Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software restart on the restarting router (a planned or unplanned outage).
17-19
17
OSPF Test Suite

OSPF Route Convergence Test Run Parameters (Continued) Description Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software reload or upgrade on the restarting router (a planned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is an unplanned switchover to a redundant control processor on the restarting router (an unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is unknown and unplanned.
Support Reason Software Reload Upgrade Support Reason Switch to Redundant Control Processor
Frame Size: Specify the sizes of the test frames sent to each destination. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. Also see Choosing
the Lowest-cost Route on page 17-17. Ensure that the two ports you select to be the receive ports are of the same media type.
Protocol: This test supports IP protocol only. See Configuring IP Addresses
on page 3-25. Using the default values for these fields, the receive port addresses are 198.18.2.2 and 198.18.3.2. Ensure that the corresponding ports on the DUT are on the same networks as the receive ports.
Pass Criteria

Table 17-9. Parameter Pass Criteria OSPF Route Convergence Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The numerical threshold value for convergence time, expressed in seconds. You can select either of two methods to calculate the convergence time: Total - The test calculates the total convergence time over a router, then it applies the criteria to determine whether a trial passed or failed. Average / withdrawal - The test averages the convergence time over a router, then it applies the criteria to determine whether a trial passed or failed. Pass: The convergence time was less than or equal to the number you entered. Fail: The convergence time was greater than the number you entered.
Convergence Time
17-20
OSPF Test Suite

Test Results
Table 17-10 describes the OSPF Route Convergence test results.

Table 17-10. OSPF Route Convergence Test Results Result TxFrames RxFrames Number of Withdrawals Number of Routes Packet Rate Tx Duration per Flap Description Number of frames transmitted. Number of frames received. Number of withdrawals configured. Number of routes configured. Transmit rate of test traffic. This value is derived from the Max Rate parameter. Length of time the test transmitted before a route flap. The test calculates this interval by multiplying the the number of withdrawals by two and dividing the Duration by the result: Duration / (No. of Withdrawals * 2) Actual Packet Loss Misdirected Packets Total Packet Loss Total Loss Number of packets lost internally by the DUT. Number of packets sent by the DUT over a withdrawn or higher-cost route. Total of misdirected packets plus lost packets. Percentage of transmitted packets lost. The test calculates this number by dividing the Total Packet Loss by the total packets transmitted, and then multiplying the result by 100: Total Loss = (Total Packet Loss / Tx Packets) * 100 Convergence Metric Convergence Metric per Withdrawal Total time spent transmitting lost packets (lost while the DUT converged away from a withdrawn route). Average time the DUT required to converge away from a withdrawn route.
How the Test Calculates the Results
When the receive port withdraws or re-advertises its routes, the DUT begins converging. While the DUT is converging, the transmit port continues transmitting. Because the DUT cannot converge instantaneously, it loses packets for two reasons: Continuing to send packets over a withdrawn route while it is in the process of converging away from it (Misdirected Packets in the results file). Not being able to buffer all the incoming packets while it has converged away from one route and is converging towards another (Actual Packet Loss in the results file).
Because Ixia receive ports are simulating the destination routers, the test can record the number packets lost to both causes. The test finds the number of mis-
17-21
17
OSPF Test Suite

OSPF Performance Test
directed packets by counting the packets that arrive on a receive port after the timestamp of the route flap. To find the number of packets discarded internally by the DUT, the test subtracts the misdirected packets from the total number transmitted and records the result as Actual Packet Loss:
Actual Packet Loss = total packets transmitted misdirected packets
The test calculates the DUTs convergence times (Convergence Metric per Withdrawal) by dividing Actual Packet Loss by the frame rate of the test, then dividing the result by the number of times the routes were flapped (withdrawn or readvertised).
Convergence Metric = Total Packet Loss / Frame Rate Convergence Metric per Withdrawal = Convergence Metric / # of Withdrawals

This section covers the following topics: Overview on page 17-22. Test Cycle on page 17-23. Supported Protocols on page 17-23. Test Setup: Run Parameters on page 17-24. Test Setup: Other Parameters on page 17-26. Pass Criteria on page 17-26. Test Results on page 17-27.
Overview
The Performance test determines the performance of the DUT by emulating the pre-defined numbers of OSPF neighbors and routes. It uses the test model shown in Figure 17-6. This test uses two Ixia ports - both to transmit and to receive. The traffic mapping is one-to-one, and the transmit direction is bidirectional.
17-22
OSPF Test Suite

Figure 17-6. OSPF Performance Test
Test Cycle
The test begins by initiating the OSPF simulation on the receive ports. The test polls the DUT once per second in order to acknowledge that it has established its own OSPF session. Then, the test starts a timer and begins advertising the route prefixes of the simulated OSPF networks to the DUT. Once the receive ports have advertised all the routes to the DUT, the test transmits frames (the size is specified by Frame Size) from the transmit ports to each route in the simulated networks. After transmitting all the frames, the test allows two seconds for any additional frames to come in, then it collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports. The linear binary search is used for calculating the DUT throughput. If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the DUT throughput. After all trials for that frame size are complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size. The test continues until all trials and frame sizes are complete. It then gathers statistics on the number of transmitted and lost packets; in the end, it calculates the Latency for all trials. After gathering statistics, it stops its OSPF session, waits for DELAY to elapse, and prints the results.
Supported Protocols
17-23
17
OSPF Test Suite

Supported Protocols
IP, IPv6, VLANs
Packet Streams
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. In order to determine the features available on your ports, see the Ixia Hardware Guide. The Capture mode is available on all ports.
Table 17-11. OSPF Performance Test Run Parameters Parameter Duration Test Parameters No. of Trials Max Rate Select the number of times you want the test to run. The rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate. The percentage of dropped packets calculated from the transmitting rate while the test is running. When the dropped packets exceed this tolerance, the rate of transmitted frames becomes lower (it is calculated using the binary search algorithm). The time, in seconds (s), to allow the DUT to finish OSPF setup at the beginning of the test. The maximum time, in seconds (s), to allow the router to absorb each route. This time is multiplied by the number of routes advertised to the router and used as the maximum wait time after all routes have been sent. The length of time the test waits for the DUT to absorb route changes. The test calculates this value by multiplying the total number of LSAs advertised by the Advertise Delay per LSA. If you check this box, the test calculates the latency. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. Detailed Results OSPF Parameters Area ID OSPF area of the emulated router. If you check this box, the detailed results are available when ending the test run. Description Specify for how long you want the test to transmit.
Loss Tolerance
DUT Processing Delay Advertise Delay Per Route
Max Wait Time
Calculate Latency Calibrate Latency
17-24
OSPF Test Suite

Table 17-11. OSPF Performance Test Run Parameters (Continued) Parameter Number of Peers per Port Increment By Number of Routes per Emulated Router First Route Subnet Mask Increment Across Routers Route Origin Description The number of prefixes to be generated for the simulated network. Increments the IP addresses between the routes. The number of prefixes advertised by each emulated router. The first IP address of the advertised prefix. The number of bits in the mask to use in creating the range of addresses. Increments the IP addresses between the simulated networks. The area where the origin route is located. You can select one of the following: Another Area External 1 External 2 Interface Network Type You can select one of the following network interfaces: Broadcast Point to Point Graceful Restart RFC 3623 Support Select to enable Graceful Restart Helper Mode on the emulated OSPF router per RFC 3623. NOTE: This option is available for OSPFv2 (using the IP protocol) only. Strict LSA Checking Select to enable Strict LSA Checking. The OSPF Restart Helper will terminate Graceful Restart when there are changes to an LSA that would be flooded to, or retransmitted by, the restarting router. Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software restart on the restarting router (a planned or unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is a software reload or upgrade on the restarting router (a planned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is an unplanned switchover to a redundant control processor on the restarting router (an unplanned outage). Select to enable Graceful Restart Helper Mode for the emulated OSPF router when the restart reason is unknown and unplanned.
Support Reason Software Reload Upgrade Support Reason Switch to Redundant Control Processor
17-25
17
OSPF Test Suite

Frame Size: Specify the sizes of the test frames sent to each destination. For further information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. Make sure that the
two ports you select as receive ports are of the same media type.
Protocol: See Configuring IP Addresses on page 3-25. Make sure that the
corresponding ports on the DUT are on the same networks as the receive ports.
VLANs: See Setting the VLAN Parameters on page 3-42 and How IxAutomate
Assigns VLAN IDs on page 3-43.
Pass Criteria

Table 17-12. OSPF Performance Test Pass Parameters Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
17-26
OSPF Test Suite

Table 17-12. OSPF Performance Test Pass Parameters (Continued) Parameter Latency Description Amount of time required by the DUT to forward frames. In order to specify the time units, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of the two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Test Results
Table 17-13 describes the OSPF Performance test results.

Table 17-13. OSPF Performance Test Results Result TxCount RxCount Tput (%) Tput (f/s) Routed ID AvgLatency MinLatency Max Latency Data Errors Description Total number of transmitted frames. Total number of received frames. Throughput expressed as a percentage of the theoretical maximum rate frame Throughput expressed in frames per second (f/s) The ID assigned to the emulated router. Average latency expressed in nanoseconds. The shortest recorded latency, in nanoseconds. The longest recorded latency, in nanoseconds. Number of received packets that contained errors.
17-27
17
OSPF Test Suite

17-28
18
Chapter 18:
Border Gateway Protocol (BGP) Test Suite

Setting Up the Tests on page 18-1.
Three IxAutomate tests are currently implemented for the BGP4 protocol: BGP Route Capacity Test on page 18-3 determines the number of routes a BGP4 router can sustain. This test uses EBGP (External BGP) only. BGP Route Convergence Test on page 18-8 tests the ability of a BGP4 router to switch between preferred and less preferred routes, when the preferred routes are withdrawn and re-advertised. This test uses EBGP (External BGP) only. BGP Performance Test on page 18-15 determines the performance of the DUT by emulating the pre-defined numbers of BGP routing sessions and routes, and calculates the throughput and latency. This test uses EBGP (External BGP) or IBGP (Internal BGP).

Most of the BGP test parameters are common to all tests, and work the same way on the three tests. The description of each test includes a description of the Run parameters for that test. The other parameters are described as follows: Protocols: All BGP tests use IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Frame Sizes: All BGP tests require you to define the frame size of the IP traffic that the test uses to test the DUT BGP routing. For information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. DUT Setup on page 18-1.
DUT Setup
To configure the DUT for the BGP tests, use its management software to: configure IP addresses on the interfaces (ports) you plan to use
18-1
18

enable BGP assign AS numbers to the ports
Sample Commands
Table 18-1 lists the basic Cisco IOS commands for configuring BGP on Cisco routers.
For the Route Capacity test and the Performance test, you only need to configure one port. For the Route Convergence test, you must configure two ports. Cisco
Table 18-1. Cisco IOS commands for BGP tests Description
Command String Global Commands: configure terminal Port Commands: interface ethernet 5 ip address 10.10.10.1 255.255.255.0 no shutdown exit router bgp 1
Enters global configuration mode from the terminal.
Selects Ethernet interface 5 for configuration. Applies an IP address and subnet mask to the selected interface. Brings up the interface. Exits global configuration mode. Enters router configuration mode and enables BGP routing with a process ID of 1. Defines IP address 10.10.10.2 as a BGP neighbor for the interface with an AS number of 2. Defines IP address 10.10.10.3 as a BGP neighbor for the interface with an AS number of 1.
neighbor 10.10.10.2 remote-as 2 neighbor 10.10.10.3 remote-as 1
18-2

BGP Route Capacity Test
Table 18-1.
Cisco IOS commands for BGP tests (Continued) Description Exits router configuration mode. Displays the configuration running on the Cache Engine for Ethernet port e5. Review the displayed configuration to ensure that it is correct.
Command String end show running-config interface e5 interface Ethernet5 ip address 10.10.10.1 255.255.255.0 no ip directed-broadcast no ip route-cache no ip mroute-cache media-type 10BaseT end ! router bgp 1 neighbor 10.10.10.2 remote-as 2 neighbor 10.10.10.3 remote-as 1

This section covers the following topics: Overview of BGP Route Capacity Test on page 18-3. Test Cycle on page 18-4. Supported Protocols on page 18-6. Test Setup: Run Parameters on page 18-6. Test Setup: Other Parameters on page 18-7. Pass Criteria on page 18-7. Test Results on page 18-8.
Overview of BGP Route Capacity Test
The route capacity test uses the test model shown in Figure 18-1. This test uses at least two Ixia portsone to transmit and one or many to receive. The traffic mapping is one-to-many, and the transmit direction is unidirectional. For a one-to-many traffic mapping, each receive port establishes a BGP session with the DUT and advertises a series of routes. As for each peer a number of routes is configurable, the total route capacity is equal to the number of routes multiplied by the number of peers.
18-3
18

DUT (B G P R o u te r)
A d v e rtis e d R o u te s
N e tw o rk T ra ffic
Tx
Rx
Rx
S im u la te d B G P R o u te r
S im u la te d B G P R o u te r
Ix ia P o rts
S im u la te d N e tw o rk R o u te s
S im u la te d N e tw o rk R o u te s
Figure 18-1. BGP Route Capacity Test
Test Cycle
The test cycle consists of the following phases: Establishing the BGP Session on page 18-4. Advertising the Routes on page 18-4. Transmitting the Test Traffic on page 18-5. Calculating the DUTs Route Capacity on page 18-5.
Establishing the BGP Session

The test begins by starting the BGP simulation on the receive ports. The test polls the DUT once per second for an acknowledgement that it has established its own BGP sessions. If the test cannot determine, within the time specified by Delay, that the DUT has established its BGP sessions, the test ends and prints an error message in the log file. Once the test determines that the DUT has started its own BGP sessions, it calculates an Estimated Delay. This is an amount of time based on the number of advertised routes that the test allows the DUT for processing.
Advertising the Routes

The test starts a timer and begins advertising the route prefixes of the simulated BGP network to the DUT. Estimated Delay determines how long the timer runs. When Estimated Delay has elapsed, the test polls the receive port to confirm that it has advertised all the routes. The Delay parameter defines the interval between polls. If, after 10 polls, the test cannot determine that all the routes have been advertised, the test ends and prints an error message in the log file.
18-4

Transmitting the Test Traffic

Once the receive ports have advertised all the routes to the DUT, the test waits for Delay, and then transmits one packet (whose size is specified by Frame Size) from the transmit port to each route in the simulated networks. After transmitting all the frames, the test collects statistics on how many of the transmitted packets the DUT forwarded to the receive ports. It then stops the BGP service on the receive ports and waits for the time specified by Delay. This ends the BGP session and should cause the DUT to age out its route table and purge its other BGP-related data structures.
Calculating the DUTs Route Capacity

When Delay has expired, the test calculates the number of packets lost by the DUT. If the test did not receive all the transmitted packets within Loss Tolerance, then the test ends and prints the results. You can choose to calculate the DUTs route capacity using the binary or the linear search. The binary search algorithm has two phases: 1. To find a bounded interval where the best solution is expected. Assuming that K represents the Initial Number of Routes Per Peer, the interval is extended step by step: [0; K], [K; 2K], [2K; 4K], [4K; 8K]. The value set for the Maximum Binary Search Step Per Peer parameter prevents the increase values for the interval from getting too large. For example, if K=1000 and Maximum Binary Search Step Per Peer is set to 100, the interval is extended as follows: [0; 2000], [2000; 2200], [2200; 2400]. 2. To find the best solution in the bounded interval using the binary search. For example, if the test did not receive all the transmitted packets within Loss Tolerance in the first interval [0; 1000], then the test decreases the number of advertised route prefixes to 500. If frames are still lost, the number of advertised routes is decreased to 250. It repeatedly retransmits with progressively lower numbers of advertised routes until the transmitted packets are received within the Loss Tolerance. The binary search process continues until the test finds the DUTs route capacity, within the specified Loss Tolerance, at which no frames are lost. The linear search algorithm calculates the DUTs route capacity as follows: If the test does receive all the transmitted packets within the Loss Tolerance, then the test increases the number of advertised route prefixes and repeats. The size of the increase is determined by the Routes Step Per Peer parameter. Each time the test repeats, it recalculates the amount of time it allows for the DUT to absorb routes before it begins transmitting. The test continues until the DUT fails to handle the advertised number of route prefixes. If you specified more than one trial, the test restarts using the
18-5
18

same frame size. After the trials for that frame size are complete, the test either ends or, if you specified more than one frame size, restarts with the next larger frame size.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, EBGP Packet Streams Receive port Capture mode
BGP Route Capacity Test Run Parameters Description
Test Parameters No. of Trials Max Rate Select the number of times you want the test to run. The rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate. The percentage of dropped packets versus transmitted packets that are allowed for a PASS condition on the test. As soon as the percentage of dropped packets exceeds this tolerance, the test stops.
Loss Tolerance
Search Type Search Type Maximum Binary Search Step Per Peer The type of the search. The available options are: Binary Search, and Linear Search. It is available only for the binary search type. Specify the maximum step per peer in order to prevent too large increase values when trying to find a bounded interval. For example, if the Initial Number of Routes Per Peer is set to 1000 and Maximum Binary Search Step Per Peer is set to 100, the resulting interval is: [0; 1000], [1000; 1100], [1100; 1200]. The difference between the real rate transmission, expressed as number of routes, in two consecutive iterations, is compared with the binary resolution value. When the difference between the transmission rate values in two consecutive iterations is smaller than the specified value for the binary resolution, the test stops.
Binary Resolution
BGP Parameters
18-6

Table 18-2. Parameter AS Number Delay
BGP Route Capacity Test Run Parameters Description The Autonomous System number associated with the simulated BGP router. Delay that allows the DUT enough time to complete processing. The first network IP address associated with the advertised routes. Select to enable graceful restart for each BGP peer. Select to restart the Ixia-emulated router at the beginning of the test (act as Restarting BGP peer). The length of time (in seconds) required after restart to re-establish a BGP session. The length of time (in seconds) after which an End-ofRIB marker is sent in an Update message to the peer. This period allows time for routing convergence by means of IGP and BGP route selection. Stale routing information for the address family is then deleted by the receiving peer.
First Network IP Address Graceful Restart Act As Restarted Restart Time Stale Time
BGP Peer Parameters Initial Number of Routes per Peer Prefix Length The number of prefixes to generate for the simulated network The length of the prefixes generated for the advertised routes. See the BGP section of the IxNetwork User Guide for a description of the algorithm used to generate BGP prefixes. The number of prefixes to add to the Routes per Peer on each iteration of the test.
Route Step Per Peer
Frame Size: Specify the sizes of the test frames sent to each destination. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. Note that this is a
two-port test only. When using the Automatic mode, a From and To range can be selected. However, the Exclude Ports tool must be used on all but two ports in the range. The first of the two ports is the Data Transmit port, while the second port brings up the BGP session.
Protocol: See Configuring IP Addresses on page 3-25 for further informa-
tion. Using the default values for these fields, the receive port addresses are 198.18.2.2 and 198.18.3.2. Make sure that the corresponding ports on the DUT are on the same networks as the receive ports.
Pass Criteria
18-7
18

BGP Route Convergence Test
BGP Route Capacity Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of minimum routes that should be verified. Pass: The minimum number of routes verified was equal to or greater than the number you entered. Fail: The minimum number of routes verified was lower than the number you entered.
Min Routes Verified
Test Results
The test uses packet loss to determine how many routes the DUT successfully managed. Because the test sends one packet over each route, it assumes that a packet that failed to arrive indicates a route that the DUT failed to use. Table 184 describes the BGP route capacity test results for each configured peer.
Table 18-4. Result Packet Rate Total Loss Tolerance Max. Routes Verified BGP Route Capacity Test Results Description Frames Transmitted / Transmit Duration Percentage of packets transmitted but not received. Configured tolerance threshold. Maximum number of routes that the DUT was able to transmit to.
Note: If you stop a test while the BGP service is running and then try to re-run it or run the other BGP test, the test fails. To ensure that the BGP service has stopped: 1. Start IxExplorer. 2. Click the plus symbol (+) next to the card used in the test to display its ports. 3. Double-click the port used in the test to display the various windows available for it. 4. Double-click the Protocol Window to display the list of protocols. 5. From the list of protocols displayed, double-click BGP to display the ports that have BGP enabled. 6. Select the port used in your test, and click Stop BGP. 7. Repeat steps 2 - 6 for any additional ports used in your test.

This section covers the following topics: Overview of BGP Route Convergence Test on page 18-9. AS Numbering on page 18-9.
18-8

Finding a Value for the Max. Rate Parameter on page 18-10. Finding the Advertise Delay per Route on page 18-10. Test Cycle on page 18-10. Supported Protocols on page 18-12. Test Setup: Run Parameters on page 18-12. Test Setup: Other Parameters on page 18-13. Pass Criteria on page 18-14. Test Results on page 18-14.
Overview of BGP Route Convergence Test
The route convergence test implements the test model shown in Figure 18-2. This test uses three Ixia ports one to transmit and two to receive. Both receive ports must be of the same media type. The traffic mapping is one-to-many, and the transmit direction is unidirectional.
DUT (BGP Router)

Advertised Routes Network Traffic
Tx
Rx
Rx
Sim ulated External BGP Router 1

Destination Routes AS 100
Simulated External BGP Router 2

AS 101
Ixia Ports
Figure 18-2. BGP Route Convergence Test
In this test, two Ixia receive (Rx) ports simulate BGP routers. Both routers advertise the same route prefixes to the simulated network. However, the routes advertised by simulated Router 1 have a shorter AS Path, which should cause the DUT to forward traffic over them instead of over simulated Router 2s routes.
AS Numbering
The test assigns the lowest AS number to the lowest-numbered receive port, and assigns the next-larger AS number to the remaining receive port. For example, if you create a traffic map by adding the following ports in the following order:
1,1,1 --> 1,1,4 1,1,1 --> 1,1,3
18-9
18

and set the First AS Number to 100, the test assigns AS numbers as follows:
1,1,3: AS 100 1,1,4: AS 101
The accuracy of this test depends on the test assuming that any packets that are lost are lost due to route convergence, not to other causes. If you set a value for MAX RATE that is too high for the DUT, it may lose packets due to throughput limitations instead of route convergence limitations. To work around this, before you run the Route Convergence test to gain actual results, you should run it to find a value for Max Rate at which the DUT loses no packets. Use the following procedure: 1. Configure the test with all the values you plan to use. 2. Set the DOWN FLAP TIME to zero (0). 3. Start the test. Configuring the test this way makes it behave like a throughput test. The results file displays the amount of packet loss on the link. If you receive any packet loss, decrease the MAX RATE, and run the test again.
Finding the Advertise Delay per Route
Configuring a usable value for Advertise Delay per Route is important to running this test successfully and without unnecessary delays. If you are not sure of what values to use for this parameter, see the Ixia Support Knowledge Base article How to Find a DUTs Route Absorption Time. Knowledge Base articles are available on Ixias web site, www.ixiacom.com. The test cycle consists of the following phases: Starting BGP on page 18-10. Advertising the Routes on page 18-10. Transmitting Frames on page 18-11.
Test Cycle
Starting BGP
The test begins by starting BGP on the receive ports. The test establishes a BGP session and then polls the DUT once per second for an acknowledgement that the DUT has established its own BGP session. If DELAY elapses before the test can confirm the DUT has started BGP, the test ends and prints an error message in the log file.

After the test determines that the DUT has started its own BGP session, the test starts a timer and begins advertising the route prefixes of the simulated BGP network to the DUT. The timer allows the DUT to absorb all the routes. The length of time the timer runs depends on whether or not you checked the Enable User Delay box:
18-10

If you checked Enable User Delay, TOTAL ADVERTISE DELAY defines how long the timer runs:
Total Advertise Delay = (Routes per peer * Advertise Delay per Route)
If you did not check Enable User Delay, the test calculates its own value for the timer.
After the timer elapses, the test polls the receive ports to confirm that they have not withdrawn any routes. The DELAY parameter defines the interval between polls. If, after 10 polls, the test cannot determine that all the routes are still available, the test ends and prints a error message in the log file. The test calculates a transmit duration that includes two withdrawals, and it also calculates UP TIME, the time when Router 1s routes are available.
Up Time = (Delay + Total Advertise Delay + Down Flap Time) Time Required for Two Withdrawals = 2 * ( Down Flap Time + Up Time + (2 * Total Advertise Delay)) Note: The formulas for the calculations described in this section assume you checked the Enable User Delay box and supplied your own value for Advertise Delay per Route. If you did not, the test uses slightly different formulas.
Transmitting Frames
After the test determines that the receive ports have retained all the routes, the test transmits one packet (whose size is specified by FRAME SIZE) to each route. The DUT should forward all the packets over the route with the shorter AS Path (Router 1 in Figure 18-2 on page 18-9). The test then withdraws the routes advertised by Router 1. Figure 18-3 shows the tests timing of the route withdrawal.
Up Time
Down Flap Time
Up Time
Down Flap Time
Total Advertise Delay Advertise
Delay Transmit
Packet Loss Withdraw
Total Advertise Delay Advertise
Delay Transmit
Packet Loss Withdraw
Transmit and Receive
Figure 18-3. BGP Convergence Test Timing
After UP TIME elapses, the receive port simulating Router 1 withdraws its routes. DOWN TIME determines how long the routes stay withdrawn. During that time, the
18-11
18

DUT should detect that the preferred route has gone down and switch traffic to Router 2s routes. Router 1 subsequently re-advertises its routes. The DUT should again detect a change and re-route traffic to the receive port simulating Router 1. The test continues until it has transmitted long enough to complete all the specified withdraw-and-advertise cycles. It then gathers statistics on the number of packets transmitted and the number lost. After gathering statistics, it stops its BGP session, waits for DELAY to elapse, and prints the results. If you specified more than one trial, the test restarts using the same frame size. After the trials for that frame size are complete, the test either ends or, if you specified more than one frame size, the restarts with the next larger frame size.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, EBGP Packet Streams Receive port Capture mode
Table 18-5. Parameter No. of Trials Max Rate
BGP Route Convergence Test Run Parameters Description Select the number of times you want the test to run. The rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate. The Autonomous System number associated with the lower-numbered simulated BGP router. The second simulated router has the next address. Length of time, in seconds, that the routes remain withdrawn. The length of the prefixes generated for the advertised routes. Refer to BGP section of the IxNetwork User Guide for a description of the algorithm used to generate BGP prefixes. The number of prefixes to generate for the simulated network. Delay that allows the DUT enough time to complete processing.
First AS Number
Down Flap Time Prefix Length
Routes per Peer Delay
18-12

BGP Route Convergence Test Run Parameters (Continued) Description Enables or disables automatic calculation of Total Advertise Delay. If you check this box, you must select a value for the Advertise Delay per Route field. If you do not check this box, the test automatically calculates the Total Advertise Delay.
Enable User Delay
Total Advertise Delay
This field displays the interval between the time the test advertises its routes and the time it begins to transmit. If Enable User Delay is checked, the test calculates Total Advertise Delay from the values you enter for Routes per Peer and Advertise Delay per Route. If Enable User Delay is not checked, the test calculates Total Advertise Delay using other values.
The time, in seconds, to allow the router to absorb each route. This time is multiplied by the number of routes advertised to the router and applied as a delay after all routes have been sent. To enter a value in this field, check the Enable User Delay check box. The network associated with the advertised routes. Select to enable graceful restart for each BGP peer. Select to restart the Ixia-emulated router at the beginning of the test (act as Restarting BGP peer). The length of time (in seconds) required after restart to re-establish a BGP session. The length of time (in seconds) after which an End-ofRIB marker is sent in an Update message to the peer. This period allows time for routing convergence by means of IGP and BGP route selection. Stale routing information for the address family is then deleted by the receiving peer.
Network IP Address Graceful Restart Act As Restarted Restart Time Stale Time
Frame Size: Specify the sizes of the test frames sent to each destination. For more information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. Make sure that the
two ports you select to be the receive ports are of the same media type. Note that this is a three-port test only. When using the Automatic mode, a From and To range can be selected. However, the Exclude Ports tool must be used on all but two ports in the range. The two ports selected from the range act as BGP ports, while the third Tx port transmits test traffic.
Protocol: See Configuring IP Addresses on page 3-25 for further informa-
tion. Using the default values for these fields, the receive port addresses are 198.18.2.2 and 198.18.3.2. Make sure that the corresponding ports on the DUT are on the same networks as the receive ports.
18-13
18

Pass Criteria

Table 18-6. Parameter Pass Criteria BGP Route Convergence Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The numerical threshold value for convergence time. You can select either of two methods to calculate the convergence time: Total - The test calculates the total convergence time over a router, then it applies the criteria to determine whether a trial passed or failed. Average / withdrawal - The test averages the convergence time over a router, then it applies the criteria to determine whether a trial passed or failed. Pass: The convergence time was equal to or lower than the number you entered. Fail: The convergence time was greater than the number you entered.
Convergence Time
Test Results
The test calculates the DUT convergence time by comparing the numbers of packets received with the number transmitted. It derives time from the transmit rate and the number of packets transmitted. Table 18-7 describes the BGP Convergence test results.
Table 18-7. Result Number of Withdrawals Packet Rate Total Loss Total Packet Loss Convergence Metric BGP Convergence Test Results Description Number of withdrawals performed. Frames Transmitted / Transmit Duration Percentage of packets transmitted but not received. Number of packets transmitted but not received. Total time spent transmitting lost packets (lost while the DUT converged away from a withdrawn route). The test calculates Convergence Metric according to the following formula: Convergence Metric = Total Packet Loss / Packet rate Convergence Metric per Withdrawal Average time the DUT required to converge away from a withdrawn route. The test calculates Convergence Metric per Withdrawal according to the following formula: Convergence Metric per Withdrawal = Convergence metric / # of Withdrawals
18-14

BGP Performance Test
Note: If you stop a test while the BGP service is running and then try to re-run it or run the other BGP test, the test fails. To ensure that the BGP service has stopped: 1. Start IxExplorer. 2. Click the plus symbol (+) next to the card used in the test to display its ports. 3. Double-click the port used in the test to display the various windows available for it. 4. Double-click the Protocol Window to display the list of protocols. 5. From the list of protocols displayed, double-click BGP to display the ports that have BGP enabled. 6. Select the port used in your test, and click Stop BGP. 7. Repeat steps 2 - 6 for any additional ports used in your test.

This section covers the following topics: Overview of the BGP Performance Test on page 18-15. Test Cycle on page 18-16. Supported Protocols on page 18-17. Test Setup: Run Parameters on page 18-17. Test Setup: Other Parameters on page 18-18. Pass Criteria on page 18-19. Test Results on page 18-20.
Overview of the BGP Performance Test
The Performance test uses the test model shown in Figure 18-4. This test uses two Ixia ports both to transmit and to receive. The traffic mapping is peer-topeer, and the transmit direction is bidirectional.
18-15
18

Figure 18-4. BGP Performance Test
Test Cycle
The test cycle consists of the following phases: Establishing the BGP Session on page 18-16. Advertising the Routes on page 18-16. Transmitting the Test Traffic on page 18-16.
Establishing the BGP Session

The test begins by initiating the BGP simulation on the receive ports. The test polls the DUT once per second for an acknowledgement that it has established its own BGP session.

The test starts a timer and begins advertising the route prefixes of the simulated BGP networks to the DUT.
Transmitting the Test Traffic

Once the receive ports have advertised all the routes to the DUT, the test transmits frames (the size is specified by Frame Size) from the transmit ports to each route in the simulated networks. After transmitting all the frames, the test collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports. The linear binary search is used for calculating the DUT throughput.
18-16

If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the DUT throughput. After all trials for that frame size are complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size. The test continues until all trials and frame sizes are complete. It then gathers statistics on the number of transmitted and lost packets; in the end, it calculates the latency. After gathering statistics, it stops its BGP session, waits for DELAY to elapse, and prints the results.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs, IBGP, EBGP Packet Streams Receive port Capture mode
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. In order to determine the features available on your ports, see the Ixia Hardware Guide. The Capture mode is available on all ports.
BGP Performance Test Run Parameters Description
Test Parameters No. of Trials Max Rate Select the number of times you want the test to run. The rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate. The percentage of dropped packets calculated at the transmitting rate while the test is running. When the dropped packets exceed this tolerance, the rate of transmitted frames becomes lower (it is calculated using the binary search algorithm). The time, in seconds (s), enabling the DUT to delay the BGP sessions. The time, in seconds (s), allowing the DUT enough time to finish the BGP setup at the beginning of the test before actually starting to transmit the test traffic. If you check this box, the test calculates the latency. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available only if the IxOS version used is at least 5.10.
Loss Tolerance
BGP Sessions Delay DUT Processing Delay Calculate Latency Calibrate Latency
18-17
18

BGP Performance Test Run Parameters (Continued) Description If you check this box, the detailed results are available when ending the test run.
Detailed Results BGP Parameters BGP Type Local AS Number
BGP Protocol: IBGP (Internal BGP) or EBGP (External BGP). The Autonomous System number associated with the simulated BGP router. For EBGP, the initial set value is automatically incremented by one; for IBGP, the initial value remains fixed. The number of emulated routers per each Ixia port. Increments the IP addresses between the routes. The number of prefixes advertised by each emulated router. The first IP address of the advertised prefixes. The number of bits in the mask to be used in creating the range of addresses. Increments the IP addresses between the emulated routers. Select to enable graceful restart for each BGP peer. Select to restart the Ixia-emulated router at the beginning of the test (act as Restarting BGP peer). The length of time (in seconds) required after restart to re-establish a BGP session. The length of time (in seconds) after which an End-ofRIB marker is sent in an Update message to the peer. This period allows time for routing convergence by means of IGP and BGP route selection. Stale routing information for the address family is then deleted by the receiving peer.
Number of peers per port Increment By Number of routes per peer First Route Subnet Mask Increment Across Routers Graceful Restart Act As Restarted Restart Time Stale Time
18-18

Pass Criteria
Table 18-9. Parameter Enable BGP Performance Test Pass Parameters Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered. Latency Amount of time required by the DUT to forward frames. In order to specify the time units, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of the two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Load Rate
18-19
18

Test Results
In addition to the standard IxAutomate test results, the following results are available in pairs (Tx and Rx): Throughput Frame count Frame loss Latency Data integrity errors
18-20
19
Chapter 19:
IS-IS Test Suite
This chapter covers the following topics: Overview of the IS-IS Test Suite on page 19-1. Setting Up the Tests on page 19-1. ISIS Performance Test on page 19-3.
Overview of the IS-IS Test Suite

The Intermediate System to Intermediate System (IS-IS) protocol is another linkstate routing protocol besides the OSPF protocol. The IS-IS protocol is a connectionless (CLNP) protocol, not a TCP/IP protocol, and it can route either a connectionless environment, an IP environment, or an environment made up of both. IxAutomate includes the following test for the IS-IS protocol: ISIS Performance Test on page 19-3 - determines the performance of the DUT by emulating the pre-defined numbers of the IS-IS routing sessions and routes. Subsequently, the test determines the throughput and latency.

Most of the IS-IS test parameters are common to many IxAutomate tests, and work the same way on all of them. The description test includes a description of the Run parameters for the test. The other parameters are described as follows: Protocols: The IS-IS test uses IP addressing. For the Protocol parameters, see Configuring IP Addresses on page 3-25. Frame Sizes: The IS-IS test requires you to define the frame size of the IP traffic used by the test to test the DUT IS-IS routing. For information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. DUT Setup on page 19-2.
19-1
19
IS-IS Test Suite

DUT Setup
In order to configure the DUT for the IS-IS test, use its management software to: configure an IP address on the interfaces (ports) you uses enable IS-IS
Sample Commands
Figure 19-1 on page 19-4 lists the basic Cisco IOS commands for configuring ISIS on Cisco routers, except for the Catalyst series, which have VLAN interfaces.
Caution: Please take all the appropriate precautions when using these sample commands. If you are not sure about how to use the commands or as to their possible effect on your DUT or network, please seek appropriate assistance. Ixia cannot be responsible for any damage that the use of the commands causes to your DUT or network.
Cisco
Table 19-1. Cisco IOS commands for IS-IS tests Description
Command String Global Commands: configure terminal Port Commands: router isis <instance_name> net 49.0111.1111.1111.1111.00
Enters the global configuration mode from the terminal.
Enables IS-IS as an IP routing protocol, and assigns a tag if there are multiple IS-IS processes. If the tag is omitted, a tag of zero (0) is assumed. Identifies the router for IS-IS by assigning a NET to the router.
interface fastEthernet 0 ip address 10.10.10.1 255.255.255.0 no shutdown
Selects a Fast Ethernet interface for the configuration. Applies an IP address and subnet mask to the selected interface. Brings up the interface.
19-2
IS-IS Test Suite

ISIS Performance Test
Table 19-1.
Cisco IOS commands for IS-IS tests Description Enables IS-IS on the interfaces participating in IS-IS. This is slightly different from most other IP routing protocols where the participating interfaces are specified by network statements. There is no network statement under the IS-IS process. If there are multiple IS-IS processes, interfaces must state which to process they belong by specifying the appropriate tag. Exits the global configuration mode.
Command String ip router isis <instance_name>
exit

This section covers the following topics: Overview of ISIS Performance Test on page 19-3. Test Cycle on page 19-4. Protocols Supported on page 19-5. Test Setup: Run Parameters on page 19-5. Test Setup: Other Parameters on page 19-7. Pass/Fail Criteria on page 19-7. Test Results on page 19-9.
Overview of ISIS Performance Test
The performance test sets up the user defined routes and topology, subsequently measuring the no-drop throughput and latency between the advertised ports. The test characterizes the performance of DUT by emulating the pre-defined numbers of IS-IS routing sessions and routes.
19-3
19
IS-IS Test Suite

ISIS Performance test

1: Ixia sends route prefixes for simulated networks to the DUT.
network range simulated IS-IS router routes to simulated network
Route Ranges
Ixia chassis
Route Ranges Ixia Chassis
IS-IS router (DUT)
2: Ixia sends one packet addressed to each route to the DUT.

traffic destinated for simulated network
Route Ranges Route Ranges
Ixia chassis
IS-IS router (DUT)
Ixia Chassis
3: DUT should forward traffic over the routes advertised by Ixia.
Figure 19-1. IS-IS Performance Test
Test Cycle
The test begins by configuring the IS-IS protocol on the receive ports. Subsequently, the IS-IS sessions are established for each port; the total number of Level 1, Level 1+2 and Level 2 sessions for each port displays. The test starts a timer and begins advertising the route prefixes of the simulated IS-IS networks to the DUT. Once the receive ports have advertised all the routes to the DUT, the test transmits frames (the size is specified by Frame Size) from the transmit ports to each route in the simulated networks. After transmitting all the frames, the test allows two seconds for any additional frames to come in, then it collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports. The linear binary search is used to calculate the DUT throughput. If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the DUT throughput. After all trials for that frame size are complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size. The test continues until all trials and frame sizes are complete. It then gathers statistics on the number of transmitted and lost packets; at the end, it calculates the Latency for all trials. After gathering statistics, it stops its IS-IS session, and prints the results.
19-4
IS-IS Test Suite

Protocols Supported

Supported Protocols Features Required on Ports Transmit port IP, IPv6, VLANs Packet Streams Receive port Capture mode
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. In order to determine the features available on your ports, please see the Ixia Hardware Guide. The Capture mode is available on all ports.
IS-IS Performance Test Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted.
Test Parameters No. of Trials Max Rate Select the number of times you want the test to run. The rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate. The percentage of dropped packets calculated based on the transmitting rate while the test is running. When the dropped packets exceed this tolerance, the rate of transmitted frames becomes lower (it is calculated using the binary search algorithm). The time, in seconds, enabling the router to absorb each route. This time is multiplied by the number of routes advertised to the router and applied as a delay after all routes have been sent. The time, in seconds (s), allowing the DUT enough time to process specific information before actually starting to transmit the test traffic. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10. IS-IS Parameters Number of Emulated Routers per Port Incremented By The number of prefixes to be generated for the simulated network. Increments the IP addresses between the emulated routers per port.
Loss Tolerance
DUT Processing Delay Calibrate Latency
19-5
19
IS-IS Test Suite

Table 19-2. Parameter Level
IS-IS Performance Test Run Parameters Description You can select the IS-IS routers level from among the following: Level 1: These routers are internal to the area. A Level 1 router is a router in a non-backbone area. Level 1+2: These routers connects areas. They connect a Level 1 area to the Level 2 backbone. Level 2: These routers are connected only to the backbone and provide transit traffic between areas.
IS-IS neighbors Holdtime
The time to live for the neighbors. If the IS-IS router does not receive any packets from a neighbor for a period of time greater than the specified value, it is t considered disabled. If enabled, the IS-IS Route Range is advertised. The number of prefixes added per port for each emulated router. The first IP address of the advertised prefixes. The number of bits in the mask to be used in creating the range of addresses. For IPv4, the default mask width is 24 bits For IPv6, the default mask width is 64 bits.
Advertise Route Range Number of Routes per Router First Route Route Mask
Increment by (per Router) Route Origin
Increments the IP addresses between the routers. The area where the origin route is located. You can select one of the following: Internal External
Advertise Network Range Number of Rows Number of Columns First Subnet IP Subnet Mask Link Type
If enabled, the ISIS Network Range is advertised. The number of rows in the emulated network range. The number of columns in the emulated network range. The first IP address to be assigned in the network range. The number of bits in the mask to be used in creating the range of addresses. You can select one of the following network interfaces: Broadcast Point to Point
Hitless Restart
Select to enable hitless restart on the router.
19-6
IS-IS Test Suite

Table 19-2. Parameter Mode
IS-IS Performance Test Run Parameters Description Select mode in which the Ixia-emulated ISIS router is to operate: Normal The adjacency with its neighbor (DUT) is established normally. Restarting The emulated router sends an IIH containing a Restart TLV with the SA bit set (Suppress Adjacency Advertisement) to the neighbor (DUT). Starting The emulated router sends to the neighbor (DUT) an IIH containing a Restart TLV with the SA bit set (Suppress Adjacency Advertisement). Helper The emulated router is acting as the Helper for the DUT that is restarting. It acknowledges the Restart TLV sent by the DUT by sending an IIH containing a Restart TLV with the RA bit set (Restart Acknowledgment).
Version
Select the version in which the router is to operate after restart: Draft v3 Draft v4
Time
The length of time (in seconds) to wait for the router to restart.
Pass/Fail Criteria
Table 19-3 on page 19-8 lists the pass criteria for this test.
19-7
19
IS-IS Test Suite

Table 19-3. Parameter Enable
IS-IS Performance Test Pass/Fail Parameters Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of the two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
Latency
The amount of time required by the DUT to forward frames. In order to specify the time units, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of the two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
19-8
IS-IS Test Suite

Test Results
Table 19-4 describes the IS-IS Performance test results.

Table 19-4. Result TxCount RxCount Tput (%) Tput (f/s) System ID AvgLatency MinLatency Max Latency Data Errors IS-IS Performance Test Results Description Total number of transmitted frames. Total number of received frames. Throughput expressed as a percentage of the theoretical maximum rate frame Throughput expressed in frames per second (f/s) The ID for the emulated IS-IS router. Average latency expressed in nanoseconds. The shortest recorded latency, in nanoseconds. The longest recorded latency, in nanoseconds. Number of received packets that contained errors.
19-9
19
IS-IS Test Suite

19-10
20
Chapter 20:
STP Test Suite
This chapter covers the following topics: Overview of the STP Test Suite on page 20-1. Setting Up the Tests on page 20-1.
IxAutomate includes the following tests: STP Convergence Test on page 20-3 measures the convergence time either by setting up a wide packet group and by time-stamping each packet on receiving ports or by counting the number of lost packets. MSTP Convergence Test on page 20-8 measures the convergence time of the DUT during a topology change in a MSTP configuration that includes two Spanning Tree Instances (MSTI) and the Common Internal Spanning Tree (CIST).
Overview of the STP Test Suite

Spanning Tree Protocol (STP) is a standard-based switching protocol that is used to avoid network loops. Switched networks are often designed with redundant paths to provide for reliability and fault tolerance, but their negative effect is the presence of switching loops. They can lead to broadcast storms that can rapidly overwhelm a network. STP is used to create a logical hierarchical tree with no loops. However, the alternate paths are still available, if necessary.

Most of the STP tests parameters are common to many IxAutomate tests and work the same way for all of them. The description of each test includes a description of the parameters, which are unique for that test. The common parameters for the STP tests are described in Run Parameters on page 20-2. Refer also to DUT Setup on page 20-2. The other parameters are described as follows:
20-1
20
STP Test Suite

Frame Sizes: The STP tests require you to define the frame size of the IP traffic used by the test to test the DUT STP routing. For information on frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: a: When the Enable Multiple Bridge Domains parameter is not checked, the STP test requires you to define three ports: The port representing the lower-cost bridge, available for receiving traffic The port representing the other available bridge (the high-cost port) for receiving traffic The port set to transmit traffic b: When the Enable Multiple Bridge Domains parameter is checked, the STP test allows you to define more than three ports. You can specify the first port in the range from which to start mapping and the last port in the range to include in the map. The number of ports used in the test is a multiple of three ports. Each sequence of three ports defines the three types of ports: The first port representing the lower-cost bridge, available for receiving traffic The second port representing the other available bridge (the high cost port) for receiving traffic The third port set to transmit traffic For more information about setting up the traffic map, see Setting Up the Traffic Map on page 3-11.
Run Parameters
Table 20-1 lists the common run parameters for STP tests:
Table 20-1. Parameter Duration STP Tests - Common Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted.
Test Parameters No. of Trials Max Rate Select the number of times you want the test to run. The rate at which frames are transmitted. Specify this as a percentage of the maximum theoretical frame rate.
DUT Setup
To configure the DUT for the STP test, use its management software to perform the following operations: configure an IP address on the interfaces (ports) you plan to use enable STP on the interfaces
20-2
STP Test Suite

STP Convergence Test
Sample Commands
Table 20-2 on page 20-3 lists the basic Cisco IOS commands for configuring STP on Cisco router, Cisco Catalyst 6509.
Caution: Please take all the appropriate precautions when using these sample commands. If you are not sure how to use the commands or as to their possible effect on your DUT or network, please seek appropriate assistance. Ixia cannot be held responsible for any damage that the use of the commands causes to your DUT or network.
Cisco
Table 20-2. Cisco IOS Commands for IS-IS Tests Description
Command String Global Commands: configure terminal Port Commands: spanning-tree mode pvst/ rapid-pvst spanning-tree extend system-id interface fastEthernet 0 no ip address switchport switchport mode trunk no shutdown exit
Enters the global configuration mode from the terminal.
Enables STP/ RSTP as an IP routing protocol. Enables the extended system ID for that bridge / switch. Selects a Fast Ethernet interface for the configuration. No IP address is needed to be applied to the interface. Enables the router port as a switch port. Enables the switch port to communicate with another switch port. Brings up the interface. Exits the global configuration mode.

This section covers the following topics: Overview of the STP Convergence Test on page 20-4. Test Cycle on page 20-4. Supported Protocols on page 20-5. Test Setup: Run Parameters on page 20-5. Pass/Fail Criteria on page 20-7.
20-3
20
STP Test Suite

Test Results on page 20-7.
Overview of the STP Convergence Test
The convergence test sets up the user-defined topology, subsequently measuring the convergence time by using the first or last timestamps method or the packet loss method. The test characterizes the convergence time of the DUT by emulating STP and RSTP topology with sequence of three ports: the first two ports used as lower-cost bridge and high-cost port, while the third port is to be used as traffic source. The convergence time is to be time delta or the time when the DUT loses packets. A one-to-many port mapping is used, with three ports or multiple of three ports.
STP Convergence
Path 1 BR1 BR2 traffic destined for simulated destination network Simulated STP lower-cost bridge (Root) Simulated STP high-cost bridge (Alternate)
Ixia TX Port Ixia TX Port 1 DUT STP Bridge

BR2 Simulated Root Bridge BR1 Simulated Destination LAN
Ixia TX Port 2
Path 2
Note: When the Enable Multiple Bridge Domains parameter is checked, you can specify more than three ports. The number of ports used in the test is always multiple of three ports. Each sequence contains one Tx port and two Rx ports. 1. The DUT learns about the emulated bridges and hosts. 2. The traffic is initially sent through Path 1. 3. The DUT forwards the frames through Path 2 when the receive ports simulating Bridge 1 interrupt its routes.
Figure 20-1. STP Convergence Test
Test Cycle
The test begins by configuring the STP protocol on the receiving ports and by setting the root cost on the emulated bridges. Subsequently, the sending streams and the filters on the receiving ports are configured. Afterwards, the sessions between the emulated bridges on the Ixia ports and the DUT are checked by sending BPDU (Bridge Protocol Data Unit) frames. Each port using STP exists in one of the following five states: blocking, listening, learning, forwarding, disabled. After the STP sessions are established, the receiving ports are waiting to reach the forwarding state; otherwise, the test cannot continue. Once the receive ports and the transmitting port know about each other, the test transmits frames (the size is specified by Frame Size; each frame contents the default IP address; no user entry is needed) from the transmit port to the lower cost bridge. The timer to trigger the convergence cause is equally started. After the cause of the convergence displays the settings implied by the convergence cause are applied. Three causes of convergence can be selected: link down, root cost or no BPDU.
20-4
STP Test Suite

After transmitting all the frames, the test allows two seconds for any additional frames to come in, then it collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports, and the convergence time is calculated. If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the convergence time. After all trials for that frame size are complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size. The test continues until all trials and frame sizes are complete. It then gathers statistics on the number of transmitted and lost packets and on convergence times. After gathering statistics, it stops STP and prints the results.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port VLANs, Layer 2-MAC, IP Packet Streams Receive port Capture mode
The STP Convergence test is a Layer-2 MAC protocol test and because of that, the Ixia ports are configured only with MAC addresses and STP protocol. The IP protocol allows you to add header IP in the generated traffic in order to simulate real traffic.
Table 20-3 describes the STP Convergence test run parameters:

Table 20-3. Parameter STP Parameters Number of MAC Addresses Per Port Cause of Convergence The number of emulated MAC addresses per port. You can select one of the following cause of convergence: Link Failure Root Cost No BPDU Bridging Protocol You can select one of the following bridging protocols: STP (Spanning Tree Protocol) RSTP (Rapid Spanning Tree Protocol) STP Convergence Test Run Parameters Description
20-5
20
STP Test Suite

STP Convergence Test Run Parameters (Continued) Description The convergence time is determined using one of the following measurement methods: First/Last Timestamps Packet Loss
Measurement Method
Root Priority
In order to set the Ixia emulated bridge as the root bridge, set the root priority value to be less or equal to the bridge priority set on the ports of the DUT connected to the Ixia Rx ports. If this setting is correct, the Ixia emulated bridge is the root bridge and the DUT can switch the traffic between the two routes advertised. The root priority is expressed in increments of 4096 units.
Root MAC Address Hello Interval (s) Max Age (s) Forward Delay (s)
You can specify the root MAC address. The period of time when the updates are sent over the network The period of time over which a route is considered to be available if no hello message was sent. The period of time representing the maximum time for forwarding a received message
Increment Values Per Bridge Domain Increment Root MAC Address Hello Interval (s) If you enable this option, the Root MAC Address is incremented for each bridge domain. The period of time when the updates are sent over the network. The time is measured per each bridge domain. The period of time over which a route is considered to be available if no hello message was sent. The time is measured per each bridge domain. The period of time representing the maximum time allowed for forwarding a received message. The time is measured per each bridge domain.
Max Age (s)
Forward Delay (s)
20-6
STP Test Suite

Pass/Fail Criteria

Table 20-4. Parameter Pass Criteria STP Convergence Test Pass/Fail Parameters Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The time interval for all the bridge domains to notice the changes appeared in the network after a route becomes unavailable, expressed in seconds (s), milliseconds (ms), microseconds (us), or nanoseconds (ns). You can select either of these two methods to calculate the time interval: Average: The test averages the time intervals over all bridge domains, then applies the criteria to determine whether a trial passed or failed. Maximum: The test selects the largest time interval over all bridge domains, then applies the criteria to determine whether a trial passed or failed. Pass: The time duration for the network to converge is lower than or equal to the time value you specified. Fail: The time duration for the network to converge is greater than the time value you specified.
Convergence Time Per Bridge Domain
Test Results
Table 20-5 describes the STP Convergence test results available per bridge domain.
Table 20-5. Result TxCount RxCount Tx Tput (f/s) Tx Tput (%) Convergence Time (ns) Conv Frame Loss Conv Frame Loss (%) STP Convergence Test Results Description Total number of transmitted frames. Total number of received frames. Throughput expressed in frames per second (f/s) Throughput expressed as a percentage of the theoretical maximum rate frame The time interval for the network to converge, expressed in nanoseconds (ns). The number of lost frames when the network is in the process of reaching the convergence. The number of lost frames, expressed as a percentage, when the network is in the process of reaching the convergence.
20-7
20
STP Test Suite

MSTP Convergence Test

This section covers the following topics: Overview of the MSTP Convergence Test on page 20-8. Test Cycle on page 20-9. Supported Protocols on page 20-10. Test Setup: Run Parameters on page 20-10. Pass/Fail Criteria on page 20-12. Test Results on page 20-13.
Overview of the MSTP Convergence Test
The test measures the convergence time of the DUT during a topology change in a MSTP configuration which includes two Spanning Tree Instances (MSTI) and the Common Internal Spanning Tree (CIST). The main enhancement introduced by the MSTP Convergence test, as compared to the STP Convergence test, is that several VLANs can be mapped to a single Spanning Tree instance. A Multiple Spanning Tree (MST) bridge must be able to handle at least two instances: one internal Spanning Tree and one or more Multiple Spanning Tree Instances (MSTIs). The MSTIs are simple RSTP instances that run the RSTP automatically, by default, without any extra configuration work. A one-to-many port mapping is used, with three ports or a multiple of three ports.
20-8
STP Test Suite

MSTP Convergence
Ixia RX Port 1
MSTI1 (VLAN 200) CIST
Ixia TX Port DUT

MSTP Bridge
BR1 Simulated Destination LAN
Ixia RX Port 2
Simulated Root Bridge
BR2 MSTI2 (VLAN 100) CIST Common Internal Spanning Tree this has no VLAN mapped MSTI1 (VLAN 100) Multiple Spanning Tree Instance 1 has assigned the VLAN 100; the traffic destined for simulated destinations network is sent through the BR1 (which is considered the Forwarding port) while the BR2 is considered the Alternate port MSTI2 (VLAN 200) Multiple Spanning Tree Instance 2 has assigned the VLAN 200; the traffic destined for simulated destinations network is sent through the BR2 (which is considered the Forwarding port) while the BR1 is considered the Alternate port Note: When the Enable Multiple Bridge Domains parameter is checked, you can specify more than three ports. The number of ports used in the test is always multiple of three ports. Each sequence contains one Tx port and two Rx ports.
Figure 20-2. MSTP Convergence Test
Test Cycle
The test begins by configuring the MSTP protocol on the receiving ports and by setting the regional roots cost on the emulated bridges. Subsequently, the sending streams and the filters on the receiving ports are configured. Each port using MSTP exists in one of the following five states: blocking, listening, learning, forwarding, disabled. After the MSTP sessions are established, the receiving ports are waiting to reach the forwarding state; otherwise, the test cannot continue. Once the receive ports and the transmitting ports are aware of each other, the test transmits frames (the size is specified by Frame Size; each frame contains the default IP address; no user entry is needed) from the transmits port to the lowercost bridges. The timer to trigger the convergence cause is equally started. After the cause of the convergence displays, the settings implied by the convergence cause are applied. Two causes of convergence can be selected: link down or root cost. After transmitting all the frames, the test allows two seconds for any additional frames to come in, then it collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports, and the convergence time is calculated. If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the convergence time. After all trials for that frame size are complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size.
20-9
20
STP Test Suite

The test continues until all trials and frame sizes are complete. It then gathers statistics on the number of transmitted and lost packets and on convergence times. After gathering statistics, it stops MSTP and prints the results. The results are printed for each MST Instance. If Enable Multiple Bridge Domains is not checked, the results for the three instances are identical. If the option is enabled, for each instance, the results differ.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port VLANs, Layer 2-MAC Packet Streams Receive port Capture mode
Table 20-6 describes the MSTP Convergence test run parameters:

Table 20-6. Parameter Test Parameters Cause of Convergence You can select one of the following causes of convergence: Link Failure Root Cost Measurement Method The convergence time is determined using one of the following measurement methods: First/Last Timestamps Packet Losses Both Swap Regional Root Cost Swap External Root Cost Initial External Root Cost equals Regional Root Cost (per port) MSTI Parameters MSTI Start VLAN ID Specify the first VLAN ID for this MST Instance (MSTI). The default value is 1. If you enable this option, the regional root path cost is swapped. If you enable this option, the external root path cost is swapped. If you enable this option, the initial external root path cost increases in order to equal the regional root path cost. MSTP Convergence Test Run Parameters Description
20-10
STP Test Suite

MSTP Convergence Test Run Parameters (Continued) Description
MSTI No. of VLAN IDs Specify the number of VLAN IDs for this MSTI. The default value is 1. Root MAC Address The 6-byte MAC address for this MSTI Root. The default value is 00 00 00 00 00 00. Root Priority The MSTI Root Priority. Set this value to be less or equal to the bridge priority set on the ports of the DUT connected to the Rx ports. If this setting is correct, the emulated bridge is the MSTI root bridge and the DUT can switch the traffic between the two advertised routes. The root priority is expressed in increments of 4096 units. The default value is 32768. Inter MSTI VLAN Increment Specify the increment value for the VLANs between MST Instances. The default value is 1. Inter MSTI Root MAC Increment Specify the increment value for the MAC addresses between the MSTI Roots. The default value is 00 00 00 00 00 00. MSTP Parameters MST Config Name The name assigned to this Multiple Spanning Tree Protocol (MSTP). The default value is Ixia. MST Config Revision The revision number for this Multiple Spanning Tree Protocol (MSTP). The default is 0. Number of MAC Addresses per Port External Root Priority The number of VLANs configured for this MSTP. The default is 1. The priority of the external root port. The root priority is expressed in increments of 4096 units. The default value is 8192. External Root MAC Address Regional Root Priority The 6-byte MAC address for the external Root bridge. The default is 00 00 00 00 00 00. The priority of the regional root port. The root priority is expressed in increments of 4096 units. The default value is 8192. Regional Root MAC Address The 6-byte MAC address for the regional Root bridge. The default is 00 00 00 00 00 00.
20-11
20
STP Test Suite

Table 20-6. Parameter Port Priority
MSTP Convergence Test Run Parameters (Continued) Description The priority of the port. The port priority is expressed in increments of 32 units. The default value is 0.
Hello Interval Max Age Forward Delay
The period of time when the updates are sent over the network. The period of time over which a route is considered to be available if no hello message was sent. The period of time representing the maximum time for forwarding a received message.
Inter Bridge Domain Increments Enable MST Config Name Increment External Root MAC Increment If you enable this option, the MST Config Name is incremented for each bridge domain. The 6-byte increment value for each additional external Root MAC address. The default is 00 00 00 00 00 00. Regional Root MAC Increment The 6-byte increment value for each additional regional Root MAC address. The default is 00 00 00 00 00 00. MSTI VLAN Increment MSTI Root MAC Increment The increment value for the MSTI VLAN ID. The default value is 2. The 6-byte increment value for each additional MSTI Root MAC Address.
Pass/Fail Criteria
20-12
STP Test Suite

MSTP Convergence Test Pass/Fail Parameters Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The time interval for all the bridge domains to notice the changes appeared in the network after a route becomes unavailable, expressed in seconds (s), milliseconds (ms), microseconds (us), or nanoseconds (ns). You can select either of these two methods to calculate the time interval: Average: The test averages the time intervals over all bridge domains, then applies the criteria to determine whether a trial passed or failed. Maximum: The test selects the largest time interval over all the bridge domains, then applies the criteria to determine whether a trial passed or failed. Pass: The time duration for the network to converge is lower than or equal to the time value you specified. Fail: The time duration for the network to converge is greater than the time value you specified.
Pass Criteria
Convergence Time Per Bridge Domain
Test Results
Table 20-8 describes the MSTP Convergence test results available per bridge domain.
Table 20-8. Result TxCount RxCount Tx Tput (f/s) Tx Tput (%) Convergence Time: Packet Loss Method (ns) Convergence Time: Timestamps Method (ns) Conv Frame Loss Conv Frame Loss (%) MSTP Convergence Test Results Description Total number of transmitted frames. Total number of received frames. Throughput expressed in frames per second (f/s) Throughput expressed as a percentage of the theoretical maximum rate frame The time interval for the network to converge, expressed in nanoseconds (ns) when the method used is Packet Loss. The time interval for the network to converge, expressed in nanoseconds (ns) when the method used is Timestamps. The number of lost frames when the network is in the process of reaching the convergence. The number of lost frames, expressed as a percentage, when the network is in the process of reaching the convergence.
20-13
20
STP Test Suite

20-14
21
Chapter 21:
Broadband Test Suite
This chapter covers the following topics: Overview of the Broadband Test Suite on page 21-1. Setting Up the Tests on page 21-3. Broadband Throughput Test on page 21-7. Broadband Back-to-Back Test on page 21-11.
Overview of the Broadband Test Suite

Two IxAutomate tests are currently implemented in order to test the performance of the broadband access systems such as: DSLAM, CMTS, WAP, or any switch. The two available tests are: Broadband Throughput Test - determines the maximum rate at which the DUT receives and forwards frames with loss lower than or equal to the specified value for loss tolerance. Broadband Back to Back Test - determines the maximum time that the DUT can receive and forward frames at the same rate with frame loss lower than or equal to the specified value for loss tolerance.
Both Broadband tests operate in an environment as shown in Figure 21-1 on page 21-2. The environment consists of one broadband device and any number of access devices. Three options are illustrated in Figure 21-1 on page 21-2: The broadband device is the CMTS device (Cable Modem Termination System) which resides in the cable company central office and the access devices are the CMs (Cable Modems) that reside on the customers premises. The broadband device is the base station device which resides in the central wireless company office (a transmission and reception station in a fixed location for handling cellular traffic), and the access devices are the MS (Mobile Stations) that reside on the customers premises.
21-1
21

Overview of the Broadband Test Suite
The broadband device is the DSLAM device (Digital Subscriber Line Access Multiplexer), which resides in the telephone company central office and receives signals from multiple customer Digital Subscriber Line (DSL) connections putting the signals on a high-speed backbone line using multiplexing techniques.
Figure 21-1. Broadband Test Suite Environment
21-2


Most of the test parameters from the Broadband tests are shared by all the tests, and work the same way. The description of each test includes a description of the parameters, which are unique for that test. The other parameters are described as follows: Protocols: The two Broadband tests use MAC addressing and IP addressing. For the MAC Protocol parameters, see Configuring MAC Addresses on page 3-19; for the IP Protocol parameters, see Configuring IP Addresses on page 3-25. For information about the parameters that are different from the standard settings for these two tests, see Protocol Parameters on page 21-4. Frame Sizes: Both Broadband tests require that you define the frame size of the IP traffic that the test uses to test the Device Under Test (broadband device and access devices). For information on frame sizes, see Choosing Frame Sizes on page 3-45. For information about the parameters that are unique for these two tests, see Bi-directional Different Frame Sizes on page 21-3. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. For information about the parameters that are unique for these two tests, see Traffic Map Parameters on page 21-5. Run Parameters on page 21-6.
Traffic Setup Parameters
This section covers the following topics: Bi-directional Different Frame Sizes on page 21-3. Protocol Parameters on page 21-4. Traffic Map Parameters on page 21-5.
Bi-directional Different Frame Sizes

These tests simultaneously transmit MAC or IP layer traffic to the access devices and broadband device for multiple frame sizes. The traffic from the WAN port to the broadband access ports is labeled as downstream traffic, while the traffic from the broadband ports to the WAN port is labeled as upstream traffic. For each traffic transmitter (access devices and broadband devices), you have a list of frame sizes and the test generates traffic in both directions at specified rates, for multiple iterations. During each iteration, the rate is incremented by a user-definable step.
NOTE: Take special precautions when selecting the frame sizes for access device and broadband device. The test runs the number of trials you specified for each combination of frame sizes. For example, if you specified 2 frame sizes for the access device and 3 frame sizes for the broadband device, the test runs 6 times.
21-3
21

Protocol Parameters
When the MAC layer protocol option is selected in the test, beside the common parameters (the options for selecting the format of the transmitted Ethernet frame) two other parameters can be set (these two parameters are unique parameters for these tests): Enable WAN VLAN - If checked, enables you to emulate multiple VLANs on the Ixia port connected to the broadband device (for example, CMTS). Each VLAN represents a host sending and receiving traffic. For the WAN port, only one VLAN is operational. Enable Broadband Access VLAN - If checked, enables you to emulate multiple VLANs on the Ixia ports connected to the access device. Each VLAN represents a host sending and receiving traffic. A single Ixia port with VLANs can emulate multiple hosts. You can use a VLAN switch in between the Ixia ports and the access device. The VLAN switch splits the traffic then feed into multiple access devices.
If you enable at least one of these two options, (either for Automatic Map or for Manual Map) two new parameters are available in the Port Names & VLAN IDs window: VLAN ID and Number of VLANs. You can set the first VLAN number and the total number of VLANs. When setting the IP protocol, in addition to the common parameters, four new parameters can be set for the broadband tests:
Enable WAN DHCP If checked, enables you to use DHCP on the Ixia port connected to the broadband device. The Ixia port obtains the IP address from the DUT. If not checked, the First Port Source Address, First Port Gateway/ DUT and Increment Gateway IP Address fields must be filled in. Enable Broadband Access DHCP If checked, enables you to use DHCP on the Ixia ports connected to the access device. The Ixia ports obtain their IP address from the access devices. If not checked, the First Port Source Address, First Port Gateway/DUT and Increment Gateway IP Address fields must be filled in. Enable WAN VLAN If checked, enables you to emulate multiple VLANs on the Ixia port connected to the broadband access device. Each VLAN represents a host sending and receiving traffic. For the WAN port, only one VLAN is functional. Enable Broadband Access VLAN If checked, enables you to emulate multiple VLANs on the Ixia ports connected to the access devices. Each VLAN represents a host sending and receiving traffic. A single Ixia port with VLANs can emulate multiple hosts. You can use a VLAN switch in between the Ixia ports and the access device. The VLAN switch splits the traffic, then feed into multiple access devices.
Even if you enable at least one of the two DHCP options, (either for Automatic Map or for Manual Map), the IP address of the DUT (the gateway address) must be set by the user. Setting the Traffic Map in Manual mode:
21-4

If you enable at least one of the two options for VLAN, then three new parameters can be set in the IP, Port Names & VLAN IDs window: VLAN ID, Number of VLANs and Octet to Auto Increment. If you enable at least one of the two options for DHCP, then the IP source address is obtained from the DHCP server.
By setting the Traffic Map in Automatic mode and enabling the two options for the DHCP server, the First Port Source Address option from the Frame Data section becomes unavailable.
Traffic Map Parameters

For the Direction parameter, you can choose one of the following options: Downstream The traffic from the WAN port to the broadband access ports Upstream The traffic from the broadband ports to the WAN port Bidirectional The port can receive and transmit at the same time.
If you choose to create a manual map, you can set the WAN ports (Source Port) and the Broadband ports (Destination Port) as shown in Figure 21-2.
Figure 21-2. Setting The Manual Map
If you choose to automatically create the map, the ports that can be excluded from the map are only the broadband ports. If you select sending traffic bidirectionally (Bidirectional option), you have to set in Binary Search Direction (located in Run Parameters) in which direction (upstream or downstream) you want to use the binary search. If you choose, for example, to use the binary search in an upstream direction, the value set in Max
21-5
21

Rate (in the upstream column) is the maximum value used when sending traffic. In the other direction (downstream, in this example), the traffic is constantly transmitted at the value set in Max Rate (in the downstream column).
Run Parameters
Table 21-1 lists the common run parameters for both Broadband tests.
Table 21-1. Parameter Duration Broadband Tests - The Common Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. Select the number of times you want the test to run. It may be necessary to run several trials of the tests in order to check the results for consistency. The number of emulated addresses defined per WAN Port. If you check this box, IxAutomate introduces a 2530ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time. Binary Search Direction You can select in which of the two directions to use the binary search. The available options are the following: Upstream Downstream Payload kbits/second Max Rate (%) The rates of the traffic sent to the broadband device and access devices, expressed in kilobits per second. The rates of the traffic sent to the broadband access device and access devices specified as a percentage of the maximum theoretical frame rate. The rates of the traffic sent to the broadband access device and access devices, expressed in frames per second.
No. of Trials
Addresses per WAN Port Staggered Transmit
Frames/Second
21-6

Broadband Throughput Test

This section covers the following topics: Overview of the Broadband Throughput Test on page 21-7. Test Cycle on page 21-7. Supported Protocols on page 21-7. Test Setup Parameters: Run Parameters on page 21-8. Pass/Fail Criteria on page 21-9. Test Results on page 21-10.
Overview of the Broadband Throughput Test Test Cycle
This test determines the maximum rate at which the DUT receives and forwards frames with loss lower than or equal to the value you specified for loss tolerance; it can also calculate the throughput with inter-arrival jitter and /or latency by using the binary search. The test starts by connecting to the chassis and creating the port mappings for the test. If the IP protocol is set, the ARP requests are sent; if the MAC protocol is set, the MAC learning frames are sent. Once the transmit and receive ports are configured, the frames are transmitted downstream and upstream (the size is specified by Frame Size for each side). The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports. The statistics are collected both for the upstream and/or for the downstream direction. Depending of the settings, the binary search is used for the upstream or the downstream traffic, in order to find out and calculate the throughput with inter-arrival jitter and/or latency. The binary search cannot be used in both directions at the same time, so the binary search is used in one direction, while the linear search is employed for the other one. If you specified more than one trial, the test restarts, using the same frame sizes. Each time the test repeats, it calculates the DUT throughput with/without interarrival jitter and/or latency. After all the trials for that frame sizes complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost packets separately for the downstream and for the upstream traffic. After gathering statistics, it prints the results.
Supported Protocols
21-7
21

Supported Protocols
IP, VLANs, OSPF, LDP, VPLS
Packet Streams/ Advanced Packet Mode (IMIX)
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. In order to determine the features available on your ports, see the Ixia Hardware Guide.
Test Setup Parameters: Run Parameters
Table 21-2. Parameter Latency Types Broadband Throughput Test Run Parameters Description Selects the method used to calculate latency: Cut Through: Delay between the time the first bit of the test frame leaves the Ixia TX port and the time it arrives on the Ixia RX port. Cut Through is normally used with switches and other devices that operate using packet header information. 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: Delay between the time the last bit of the test frame leaves the Ixia TX port and the time its first bit arrives on the Ixia RX port. Store and forward latency is calculated by first determining the Cut Through delay and then substracting the frame length time. Store and Forward is normally used with routers and other devices that operate on the contents of the entire packet. The last transmitted data bit is usually the end of the FCS or CRC, and the first data bit received is as described above for Cut Through. Calculate Latency Calibrate Latency If you check this box, the test calculates the latency. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available only if the IxOS version used is at least 5.10. Calculate Inter-Arrival If you check this box, the test calculates the interarrival jitter.
21-8

Broadband Throughput Test Run Parameters Description If you check this box, the test calculates the data integrity. You can select one of the following search types: Binary Linear
Measure Data Integrity Search Types
For information on other tests in this family, see Broadband Test Suite on page 21-1. For further information on IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria
The pass/fail criteria available for this test are listed in Table 21-3.
Table 21-3. Parameter Pass Criteria Broadband Throughput Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
21-9
21

Broadband Throughput Test - Pass/Fail Criteria (Continued) Description The amount of time required by the DUT to forward frames. In order to specify the time units, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of the two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Inter-Arrival
Amount of variation from the average in the DUTs latency. In order to specify the time units, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of the two methods to calculate the inter-arrival: Average/Port: The test averages the inter-arrival over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest interarrival experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The inter-arrival was less than the value you specified. Fail: The inter-arrival exceeded the value you specified.
Test Results
Table 21-4 describes the Broadband Throughput test results, available both for downstream traffic and for upstream traffic:
Table 21-4. Parameter TxFrames RxFrames TxTput (f/s) %TxTput Loss (frames) Loss (%) Broadband Throughput Test Results Description Total number of transmitted frames. Total number of received frames. Throughput expressed in terms of frames per second (f/s) Throughput loss expressed in terms of frames (the total number of lost frames) Frame loss expressed as a percentage of the total number of transmitted frames
21-10

Broadband Back-to-Back Test

This section covers the following topics: Overview of the Broadband Back-to-Back Test on page 21-11. Test Cycle on page 21-11. Supported Protocols on page 21-11. Test Setup Parameters: Run Parameters on page 21-12. Pass/Fail Criteria on page 21-12. Test Results on page 21-12.
Overview of the Broadband Back-toBack Test Test Cycle
This test determines the maximum time that the DUT can receive and forward frames with frame loss lower than or equal to the value you specified for loss tolerance.
The test starts by connecting to the chassis and creating the port mappings for the test. If the IP protocol is set, the ARP requests are sent; if the MAC protocol is set, the MAC frames are sent. Once the transmit and receive ports are configured, the frames are transmitted downstream and upstream (the size is specified by Frame Size for each side). The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports. The statistics are collected both for the upstream and for the downstream direction. Depending of the settings, the binary search is used for the upstream or the downstream traffic. The binary search cannot be used on both directions at the same time, so the binary search is used for one direction, while the linear search is used for the other one. If you specified more than one trial, the test restarts, using the same frame sizes. After all the trials for that frame sizes complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all trials and frame sizes complete. It then gathers statistics on the number of received frames without loss for each port and the most important test configuration details. After gathering statistics, it prints the results.
Supported Protocols
21-11
21

Supported Protocols
IP, Layer2-MAC, VLANs, DHCP
Packet Streams/ Advanced Packet Mode (IMIX)
If you select a port for this test that does not support these features, IxAutomate drops that port from the port list. In order to determine the features available on your ports, see the Ixia Hardware Guide.
The Run parameters for this test are common to the other Broadband tests; see Table 21-1 on page 21-6. For information on other tests in this family, see: Broadband Test Suite on page 21-1.
For further information on IxAutomate testing in general, see: Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria
The pass/fail criteria available for this test are listed in the following table (Table 21-5):
Table 21-5. Parameter Pass Criteria Broadband Back-to-Back Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The minimum period of time for continuously transmitting frames without packet loss. To specify the time units select seconds (s), milliseconds (ms), or microseconds (us) from the drop-down list. Pass: The DUT transmitted or received frames for a period equal to or greater than the value you entered. Fail: The DUT transmitted or received frames for a shorter period of time than the value you entered. Min BackToBack Frames The minimum number of frames that the DUT is able to transmit and receive. Pass: The DUT transmitted and received a number of frames equal to or greater than the rate you entered. Fail: The DUT transmitted and received a number of frames lower than the rate you entered.
Minimum Duration
Test Results
Table 21-6 describes the Broadband Back-to-Back test results, available both for the downstream and for the upstream traffic:
21-12

Table 21-6. Parameter TxFrames RxFrames
Broadband Back-to-Back Test Results Description Total number of transmitted frames. Total number of received frames. The number of lost frames. Frame loss expressed as a percentage of the total number of transmitted frames The largest numbers of frames that each port received without loss. Number of received packets containing errors.
Loss (Frames) Loss (%) Back to Back Frames Data Integrity Errors
21-13
21

21-14
22
Chapter 22:
RFC 3511 Test Suite
This chapter covers the following topics: Overview of the RFC 3511 Test Suite on page 22-1. Setting Up the Test on page 22-4. Test Reports on page 22-8. IP Throughput Test on page 22-8. TCP Connections Capacity Test on page 22-12. Maximum TCP Connection Establishment Rate Test on page 22-14. Denial of Service Handling Test on page 22-17. HTTP Transfer Rate Test on page 22-20. Maximum HTTP Transaction Rate Test on page 22-23. Illegal Traffic Handling Test on page 22-26. IP Fragmentation Handling Test on page 22-30. Latency Test on page 22-34.
Overview of the RFC 3511 Test Suite

The RFC 3511 tests are currently implemented in order to provide support for testing firewalls. The firewalls can control access between networks. Usually, a firewall protects a private network (such as a corporate or home network) from a public or shared network (such as the Internet) to which it is connected. A firewall can be as simple as a single device that filters packets or as complex as a group of devices that combine packet filtering and application-level proxy and network translation services. This section covers the following topics: Choosing Which Tests to Run on page 22-2.
22-1
22
RFC 3511 Test Suite

Testing the Firewall Using the Ixia Hardware on page 22-2. How Can the Traffic Be Generated From an Ixia Port? on page 22-3.
Choosing Which Tests to Run
Because each test in the suite tests performance by stressing different parameters, you should run all the tests to gain a comprehensive picture of the DUTs performance. IxAutomate includes the following tests: IP Throughput test determines the maximum rate at which the DUT receives and forwards frames with loss lower than or equal to the specified value for loss tolerance. The test measures the forwarding firewall capacities. TCP Connection Capacity test determines the maximum number of concurrent TCP connections supported through or with the DUT. The test measures the connection firewall capacities. Maximum TCP Connection Establishment Rate test determines the maximum TCP connection establishment rate through or with the DUT. This test measures the connection firewall capacities. Denial Of Service Handling test determines the effect of a denial of service attack on a DUT TCP connection establishment. The test measures the connection firewall capacities. HTTP Transfer Rate test determines the transfer rate of a HTTP requested object traversing the DUT. The test measures the connection firewall capacities. Maximum HTTP Transaction Rate test determines the maximum transaction rate the DUT can sustain. The test measures the connection firewall capacities. Illegal Traffic Handling test determines the behavior of the DUT when a combination of both legal and illegal traffic is sent. The illegal traffic does not refer to an attack, but to the traffic that has been explicitly defined by (a) rule(s) to drop. The test measures the filtering firewall capacities. IP Fragmentation Handling test determines the performance impact when the DUT is presented with IP fragmented traffic. The test measures the forwarding firewall capacities. Latency test determines the latency of network-layer or application-layer data passing the DUT. The test measures the firewall latency characteristics.
Testing the Firewall Using the Ixia Hardware
The Ixia chassis acts as a traffic generator for the both the protected and for the unprotected networks. The firewall must be connected to at least two Ixia ports, one for the protected network traffic, and the other one for the unprotected network traffic. As RFC 3511 specifies, the traffic direction through the firewall is from the client applications connected to the corresponding servers as shown in Figure 22-1. You can define the client applications network and the server applications network.
22-2
RFC 3511 Test Suite

Figure 22-1. Traffic Direction Through the Firewall
Some useful entities are defined below: Client Traffic defines the traffic generated by the client application (for example, http client) Client Network defines the network of the client applications. Client Network Range is the main component of the Client Network and it defines a number of hosts from the same subnet. A Client Network contains one or more Client Network Ranges. Server Traffic defines the behavior of the server application (for example, http server) Server Network defines the network of the server applications. Server Network Range is the main component of the Server Network and it defines a number of hosts from the same subnet. A Server Network contains one or more Server Network Ranges.
To be able to link these entities, it is important to define the relation between them: There is a one-to-many relation between the Client Network entity and the Client Traffic entity, which means that one Client Network can handle many types of Client Traffic. There is a one-to-many relation between the Server Network entity and the Server Traffic entity, which means that one Server Network can handle many types of Server Traffic. There is a one-to-many relation between the Client Network or the Server Network and the Ixia port, which means that the traffic from a single network can be distributed to many Ixia ports. However, one Ixia port can be assigned to one Client Network only.
How Can the Traffic Be Generated From an Ixia Port?
There are two possibilities for generating the traffic from an Ixia port:
22-3
22
RFC 3511 Test Suite

Setting Up the Test
1. From a client network composed of the network ranges from the same subnet without passing through any gateway before the firewall. In this case, the firewall is part of the Client Network and can handle the traffic received on the interface connected to the Ixia port.
NOTE: In this case, the Network Ranges mapped to the Client Network must be on the same subnet.
2. From a client network composed of the network ranges from different subnets by passing through a router gateway before the firewall. In this case, the traffic from the Ixia port is sent from an emulated router. The firewall interface connected to the Ixia port can handle the traffic from that emulated router. If you want to simulate traffic from different subnets, you can choose one of the the two possibilities: You can define two Client Networks, each with one Network Range representing a subnet. However, it requires two Ixia ports as long as one Ixia port can be assigned to one Client Network only. You can define one Client Network with two Network Ranges, one for each subnet. In this case, only one Ixia port is required.
NOTE: If the Client Network is mapped to many Ixia ports, then the Network Ranges are distributed in a round robin manner across the ports.
Setting Up the Test

Most of the test parameters from the RFC 3511 tests are shared by all the tests, and work the same way. The description of each test includes a description of the parameters, which are unique for that test. The common parameters for the RFC 3511 tests are described in the following sections: Network Setup parameters: see Traffic Setup Parameters on page 22-4. Test Setup parameters: see Run Parameters on page 22-7.
You can configure the client network(s), the server network(s) and to set the parameters for each of them. In the section below is described the way you can define the client network. To define the server network, you can use the same directions as for defining the client network.
NOTE: For any of the RFC 3511 tests at least one client network and one server network must be configured and properly mapped to the corresponding Ixia port(s). One network can be mapped to more ports, but the means of communication with the destination DUT port(s) must exist and be properly configured.
This section covers the following topics:
22-4
RFC 3511 Test Suite

Setting Up the Test
Defining the Client Network on page 22-5. Adding Port Mappings For The Configured Networks on page 22-6. Firewall Parameters on page 22-8.
Defining the Client Network

A client network can contain many network range components. The total number of clients for a network is the sum of the clients for each network range contained by the specified network. To add a new client network, click Client Network in the Network/Network Range pane and then click the set it and then click the button. To delete an existing client network, button.
Table 22-1 on page 22-5 lists the parameters you must set for a client network. These parameters are enabled only for the client networks. Otherwise, they are disabled.
Table 22-1. Parameter IP Source Port Range Client Network - Parameters Description Description From: It defines the beginning of the range for the port numbers used to establish TCP connections. The default value is 1024. To: It defines the end of the range for the port numbers used to establish TCP connections. The default value is 65535. MAC Mapping Mode You can choose how to assign the MAC addresses for each host. The following options are available: MAC Per IP: For each host, its own MAC address is set at layer two. MAC Per Port: An emulated router must be configured and the packets sent from each host have assigned its MAC address. You can map the MAC addresses separately in the MAC Mapping Setup window that opens when clicking the Configure button.
To add a new client network range for a certain client network, click the client network, for example Client Network_0, in the Network/Network Range pane and then click the and then click the button. To delete an existing client network range, set it button.
22-5
22
RFC 3511 Test Suite

Setting Up the Test
Table 22-2 lists the parameters you must set for a network range. These parameters are enabled only for the client network ranges. Otherwise, they are disabled.
Table 22-2. Parameter First IP Client Network Range - Parameters Description Description The first IP address for the network range. Here you can set the first IP address you want for the network range you are defining. The default value is 198.18.1.1. The first MAC address for the network range. The default value is 00:C6:12:02:01:00. The IP address of the gateway associated with all the IP addresses from the network range. The default value is 0.0.0.0. The number of unique IP addresses in the network range. It defines the octet to be incremented from the IP address and the incrementing step (for example, 0.0.1.0 increments the third octet with step 1). The default value is 0.0.0.1 and the allowed values are the following: 1.0.0.0, 0.1.0.0, 0.0.1.0 and 0.0.0.1. It defines the octet to be incremented from the MAC address and the incrementing step. The default value is 00.00.00.01.00.00. It defines the subnet mask associated with the IP addresses. The default value is: 255.255.0.0.
First MAC Gateway IP
Number of Hosts IP Step Size
MAC Step Size
Network Mask
Adding Port Mappings For The Configured Networks

You can configure the traffic map for the defined networks using the Assign Port button. If you are connected to a valid chassis, then a dialog window opens and you can set the mappings (as shown in Figure on page 22-7). The mappings are added only if you click the Apply button after you have finished making the configuration.
22-6
RFC 3511 Test Suite

Setting Up the Test
Figure 22-2. Setting the Traffic Map
Run Parameters
Table 22-3 lists the common run parameters for RFC 3511 tests:
Table 22-3. Parameter Duration RFC 3511 - Common Run Parameters Description The duration of the test in hours, minutes and seconds. It is the time for which the virtual client(s) are to sustain the test objective. Select the number of times you want the test to run. It may be necessary to run several trials of the tests in order to check the results for consistency. Set a value for the tolerance you want to be allowed for the final result. It may be better to set a small value in order to obtain an accurate result.
No. of Trials
Search Tolerance
Response Object Size The number of bytes for the response message, excluding any bytes associated with the http header. Requests Per Connection The maximum number of object requests attempted per connection. If you set the 0 value, IxAutomate tries to create as many requests per connection as possible.
22-7
22
RFC 3511 Test Suite

Test Reports
RFC 3511 - Common Run Parameters Description Specify the number of connections per second you are expecting the DUT to establish. It represents the target value for the first iteration in the iterative search algorithm. The number of users brought online simultaneously during the sustain time.
Expected connections rate
Simulated Users
Firewall Parameters
Table 22-4 lists the configurable parameters for the firewall. These parameters are reported in the RFC3511.csv file.
Table 22-4. Parameter Aging Time(s) RFC 3511 Tests - Firewall Parameters Description The time for which the DUT keeps a connection in its connection table after receiving a TCP FIN or RST packet.
Test Reports
When running a test, IxAutomate creates a set of CSV (comma-separated value) files containing the test results. IxAutomate stores the generated CSV files in: installation directory\Results. In addition to the common CSV files generated for every test (for more information about this, see Chapter 3, Accessing CSV Output), for the RFC 3511 tests, the RFC3511.csv file is generated. The file contains the following information: HTTP version, NAT enable, aging time, response object size, number of hosts from client networks, number of hosts from server networks, requests per connection, close method, close direction. The new CSV file can be loaded into any standard spreadsheet program (or any application that reads CSV files) to analyze the data and it is stored in the same directories as all the other CSV files. For more information about this, see Chapter 3, Creating and Running IxAutomate Tests.
IP Throughput Test
This section covers the following topics: Overview of the IP Throughput Test on page 22-9. Test Cycle on page 22-9.
22-8
RFC 3511 Test Suite

IP Throughput Test
Traffic Setup Parameters: IP Setup & IP Protocol on page 22-9. Test Setup Parameters: Run Parameters on page 22-10. Pass/Fail Criteria on page 22-11. Test Results on page 22-11.
Overview of the IP Throughput Test
This test determines the maximum rate at which the DUT receives and forwards frames with loss lower than or equal to the specified value for loss tolerance. The test emulates clients and servers and a binary search algorithm is used to obtain the DUTs throughput. The test starts by connecting to the chassis, configuring the client and server networks you set, and creating the port mappings for the test. Also, the ARP requests are sent at the beginning of the test. Once the transmit and receive ports are configured, the packets are transmitted (the Packet Size parameter is configurable). The test allows two seconds for any additional packets to come in. After transmitting all the packets, the test collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports. The binary search algorithm is used to find out and calculate the DUT throughput. The value you specified for the Initial Rate parameter is the target value for the first trial of the first iteration. If you specified more than one trial, the test restarts, using the same packet size. Each time the test repeats, it calculates the DUT throughput. After all the trials for that packet size complete, the test either ends or, if you specified more than one packet size for one part, it restarts with the next largest packet size. It is recommended to perform the throughput measurements with different packet sizes. When testing with different packet sizes, the DUT configuration should remain the same. The test continues until all the trials and packet sizes complete. It then gathers statistics on the number of transmitted and lost packets. After gathering statistics, it prints the results.
Test Cycle
Traffic Setup Parameters: IP Setup & IP Protocol
For more information about the common traffic parameters, see Traffic Setup Parameters on page 22-4. Table 22-5 on page 22-10 lists the IP Setup parameters that are different from the standard settings you must set for this test:
22-9
22
RFC 3511 Test Suite

IP Throughput Test
Table 22-5. Parameter Packet Size
IP Throughput Test - IP Setup Parameters Description Three modes for selecting packet sizes are available: Standard mode uses a list of packet sizes defined by RFC 2544. NOTE: The minimum packet size available for this test is 80, not 64, as indicated in the graphical interface. When running a test, a warning message displays containing information about this. Automatic mode uses a range of packet sizes which you define and increments them by a value which you can select as well. Manual mode allows you to define your own packet sizes. For more information about how to select the packet sizes, see: Chapter 3, Choosing Frame Sizes.
IP Protocol
You can select the protocol you want to emulate as traffic client. The available protocols are: TCP HTTP FTP
For more information about the common parameters, see Run Parameters on page 22-7. For this test, take into account the note below in addition to the description of the Duration parameter.
NOTE: It is recommended that the Duration parameter be set to at least 30 seconds (s).
Table 22-6. Parameter Initial Rate (%) IP Throughput Test - Run Parameters Description The initial rate at which packets are transmitted. Specify this as a percentage of the maximum theoretical packet rate of the port. The percentage of total packets sent allowed to be lost before declaring packet loss.
Loss Tolerance (%)
For information about other tests in this family, see RFC 3511 Test Suite on page 22-1.
22-10
RFC 3511 Test Suite

IP Throughput Test
For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria
Table 22-7. Parameter Pass Criteria IP Throughput Test - Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Load Rate
Test Results
Table 22-8 describes the IP Throughput test results.

Table 22-8. Parameter %TxTput TxTput (pps) TxCount RxCount Tx Packets Sent (all ports) Rx Packets Received (all ports) IP Throughput Test - Test Results Description Transmit throughput, as a percentage of the theoretical maximum port speed. Transmit throughput expressed in packets per second. Total number of transmitted packets per port. Total number of received packets per port. The total number of sent packets from all the transmitting ports The total number of received packets from all the receiving ports.
22-11
22
RFC 3511 Test Suite

TCP Connections Capacity Test
IP Throughput Test - Test Results Description The rate of the lost packets, expressed as a percentage of the total sent packets. The rate of the successfully forwarded packets to the correct destination interface, expressed as a percentage of the maximum theoretical line capacity.
Loss Rate (%) Forwarding Rate (%)

This section covers the following topics: Overview of the TCP Connections Capacity Test on page 22-12. Test Cycle on page 22-12. Test Setup Parameters: Run Parameters on page 22-13. Pass/Fail Criteria on page 22-13. Test Results on page 22-14.
Overview of the TCP Connections Capacity Test
This test determines the maximum number of concurrent TCP connections supported through or with the DUT. It is intended to find the maximum number of entries the DUT can store in its connection table. An iterative search algorithm is used to determine the DUTs capacity connections, and for this is used a set of http client(s) configured to simultaneously initiate connections to the http server(s). The test starts by connecting to the chassis and configuring the client and server networks that you set for the test. The client network contains a set of http client(s) and the server network, a set of http server(s). Once the networks are configured, the test starts the iterative search algorithm to determine the maximum number of TCP concurrent connections supported by the firewall. The value specified for the Expected number of concurrent connections parameter, including also the search tolerance value, determines the number of iterations necessary to reach the DUTs capacity. The number you set for this parameter represents the target value for the first iteration. If the set value is higher than the number of connections the DUT can establish simultaneously, the test determines the number of performed connections during the first iteration. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the maximum capacity connections. After each trial, the test collects statistics on how many connections were established and then prints the results. If the set value is lower than the number of connections the DUT can establish simultaneously, the test needs more than one iteration to determine the maximum number of concurrent connections. Starting with the second iteration, the target value for expected number of concurrent connections is calculated using the binary search. When the value becomes higher than the DUTs
Test Cycle
22-12
RFC 3511 Test Suite

capacity, the test determines the number of performed connections. If you specified more than one trial, the test continues until all trials complete. After each trial, the test collects statistics on how many connections were established and then prints the results.
Table 22-9. Parameter Expected number of concurrent connections TCP Connections Capacity Test - Run Parameters Description Set the initial number of the concurrent connections you are expecting the DUT to establish. If the number is too small as compared to the DUTs capacity, a large number of iterations is executed. You can set the number of connections you want a user to establish.
Connections/User
For information about other tests in this family, see RFC 3511 Test Suite on page 22-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria
The pass/fail criteria available for this test are listed in Table 22-10:
Table 22-10. TCP Connections Capacity Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of connections that the DUT should be able to establish. You can select either of the two methods to calculate the number of established connections: Average/Port: The test averages the number of established connections over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest number of established connections measured on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT established a number of connections equal to or greater than the value you entered. Fail: The DUT established a number of connections lower than the value you entered.
Established Connections
22-13
22
RFC 3511 Test Suite

Maximum TCP Connection Establishment Rate Test
Test Results
Table 22-11 describes the TCP Connections Capacity test results. Not all the statistics are available for one port. If the port is set to send requests, it cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics both for the HTTP requests sent and for the HTTP requests received.
Table 22-11. TCP Connections Capacity Test - Test Results Parameter Concurrent Connections Connections Completed Rate(%) HTTP Requests Sent HTTP Requests Received HTTP Requests Completed Rate (%) HTTP Responses Sent HTTP Responses Received HTTP Responses Completed Rate (%) HTTP Response Bytes Sent HTTP Response Bytes Received Description The total number of TCP concurrent connections established during the last iteration performed in the search algorithm. The percentage of TCP completed connections measured against the expected TCP concurrent connections. The total number of HTTP requests sent by the http clients for establishing connections. The total number of HTTP requests received by the servers. The percentage of sent HTTP requests measured against the received HTTP requests. The total number of HTTP responses sent by each port set as server. The total number of responses received by each port set as client. The percentage of sent HTTP responses measured against the HTTP responses received for each port. The total number of bytes contained in all the HTTP responses sent by the servers for each port. The total number of bytes contained in all the HTTP responses received by each port set as client port.

This section covers the following topics: Overview of the Maximum TCP Connection Establishment Rate Test on page 22-15. Test Cycle on page 22-15. Test Setup Parameters: Run Parameters on page 22-15. Pass/Fail Criteria on page 22-15. Test Results on page 22-16.
22-14
RFC 3511 Test Suite

Overview of the Maximum TCP Connection Establishment Rate Test Test Cycle
This test determines the maximum TCP connection establishment rate through or with the DUT. It is intended to find the maximum rate at which the DUT can update its connection table. An iterative search algorithm is used to determine the maximum rate, and for this are used a set of http client(s) and a set of http server(s). Each http client is configured to initiate connections to each server host from the server network(s). The test starts by connecting to the chassis and configuring the client and server networks you set for the test. The client network contains a set of http client(s) and the server network, a set of http server(s). Once the networks are configured, the test starts the iterative search algorithm to determine the maximum TCP connection establishment rate supported by the firewall. The value specified for the Expected connections rate parameter, including the search tolerance value, determines the number of iterations necessary to reach the DUTs capacity. The number you set for this parameter represents the target value for the first iteration. If the set value is higher than the establishment connection rate the DUT can perform, the test determines the number of performed connections during the first iteration. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the maximum TCP connection establishment rate. After each trial, the test collects statistics and then prints the results. If the set value is lower than the establishment connection rate the DUT can perform, the test needs more than one iteration to determine the maximum TCP establishment connection rate. Starting with the second iteration, the target value for expected connections rate is calculated using the binary search. When the value becomes higher than the DUTs capacity, the test determines the number of performed connections. If you specified more than one trial, the test continues until all trials complete. After each trial, the test collects statistics and then prints the results.
For more information about the common run parameters, see Run Parameters on page 22-7. For information about other tests in this family, see RFC 3511 Test Suite on page 22-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria
The pass/fail criteria available for this test are listed in Table 22-12 on page 2216:
22-15
22
RFC 3511 Test Suite

Table 22-12. Maximum TCP Connection Establishment Rate - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of connections per second that the DUT should be able to establish. You can select either of the two methods to calculate the establishment connection rate: Average/Port: The test averages the number of connections established over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest number of established connections measured on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT established a number of connections equal to or greater than the value you entered. Fail: The DUT established a number of connections lower than the value you entered.
Connections Rate
Test Results
Table 22-13 describes the Maximum TCP Connection Establishment Rate test results. Not all the statistics are available for one port. If the port is set to send requests, it cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics both for the HTTP requests sent and for the HTTP requests received.
Table 22-13. Maximum TCP Connection Establishment Rate - Test Results Parameter Connections Rate Description The total number of TCP connections per second, established during the last successful iteration performed in the search algorithm The total number of HTTP requests sent by the clients in order to establish connections The total number of HTTP requests received by the servers The percentage of sent HTTP requests measured against the received HTTP requests. The total number of sent HTTP responses. The total number of HTTP responses received. The percentage of sent HTTP responses measured against the received HTTP responses.
HTTP Requests Sent HTTP Requests Received HTTP Requests Completed Rate (%) HTTP Responses Sent HTTP Responses Received HTTP Responses Completed Rate (%)
22-16
RFC 3511 Test Suite

Denial of Service Handling Test
Table 22-13. Maximum TCP Connection Establishment Rate - Test Results (Continued) Parameter HTTP Response Bytes Sent HTTP Response Bytes Received Description The number of bytes from all the http responses sent for each port The number of bytes from all the http responses received for each port

This section covers the following topics: Overview of the Denial of Service Handling Test on page 22-17. Test Cycle on page 22-17. Test Setup Parameters: Run Parameters on page 22-18. Pass/Fail Criteria on page 22-19. Test Results on page 22-19.
Overview of the Denial of Service Handling Test
This test determines the effect of a denial of service attack on a DUT TCP connection establishment rate. The TCP SYN flood attack exploits the TCPs three handshake mechanism by sending TCP SYN attack segments. An iterative search algorithm is used to determine the maximum rate, and for this are used a set of http client(s) and a set of http server(s). Each http client is configured to initiate connections to each server host from the server network(s). During a trial of the test, it runs first with the denial of service attack enabled and secondly, with the denial of service attack disabled. You can compare the results obtained for these two situations and the difference represents the effect of the denial of service attack on the DUT performance.
Test Cycle
The test starts by connecting to the chassis and configuring the client and server networks you set for the test. The client network contains a set of http client(s) and the server network, a set of http server(s). The source hosts may be: If you choose the Client Network option, the client networks you configured in the test. If you choose the Custom Range option, the hosts with the IP address contained in the Custom Range you defined.
Once the sending and receiving ports are configured, the test starts the iterative search algorithm to determine the maximum TCP connection establishment rate supported by the firewall. At the same time, the SYN flood packets are sent to the DUT. The value specified for the Expected connections rate parameter, including the search tolerance value, determines the number of iterations necessary to
22-17
22
RFC 3511 Test Suite

reach the DUTs capacity. The number you set for this parameter represents the target value for the first iteration. If the set value is higher than the establishment connection rate the DUT can perform, the test determines the number of performed connections during the first iteration. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the maximum TCP connection establishment rate. After each trial, the test collects statistics and then prints the results. If the set value is lower than the establishment connection rate the DUT can perform, the test needs more than one iteration to determine the maximum TCP establishment connection rate. Starting with the second iteration, the target value for expected connections rate is calculated using the binary search algorithm. When the value becomes higher than the DUTs capacity, the test determines the number of performed connections. If you specified more than one trial, the test continues until all trials complete. After each trial, the test collects statistics and then prints the results.
For more information about the common run parameters, see Run Parameters on page 22-7. Table 22-14 lists the run parameters that are different from the standard settings or unique for this test.
Table 22-14. Denial Of Service Handling Test - DDoS Parameters Parameter Description
DDoS Parameters (Distributed Denial of Service) DoS Attack From The Network Attack Port Burst Size The client network that generates the attack. The client networks you set for your test are available in the drop-down list and you can choose one of them. The TCP destination port set in the TCP SYN attack packets. The number of packets contained in each attack burst. The minimum value you can set from the graphical user interface is 1. If you set the value to 1, it means that the traffic is transmitted as constant loading. If you are running the test from the command line for a value lower than or equal to 0, the test is aborted with an error message. Burst Rate The rate at which the packets are sent in each burst. The minimum value you can set from the graphical user interface is 1. If you are running the test from the command line for a value lower than or equal to 0, the test is aborted with an error message.
22-18
RFC 3511 Test Suite

Table 22-14. Denial Of Service Handling Test - DDoS Parameters (Continued) Parameter Number of Users Performing DoS Attacks Description The number of users that simulate an application performing SYN attacks in concordance with the configured rules. The application is deployed on the hosts from the client networks performing DoS (Denial of Service). If the number of users is greater than the number of hosts, there is a set of users using the same host. The user attacks are performed simultaneously.
Source Hosts Client Network Custom Range The hosts used to perform the DoS attack is the set of clients from the configured client network. The hosts used to perform the DoS attack are the hosts from the range you defined.
Pass/Fail Criteria
Table 22-15. Denial of Service Handling Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of connections per second that the DUT should be able to establish. You can select either of the two methods to calculate the establishment connection rate: Average/Port: The test averages the number of connections established over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest number of established connections measured on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT established a number of connections equal to or greater than the value you entered. Fail: The DUT established a number of connections lower than the value you entered.
Connections Rate
Test Results
Table 22-16 on page 22-20 describes the Denial of Service Handling test results. Not all the statistics are available for one port. If the port is set to send requests, it
22-19
22
RFC 3511 Test Suite

HTTP Transfer Rate Test
cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics both for the HTTP requests sent and for the HTTP requests received.
Table 22-16. Denial Of Service Handling Test - Test Results Parameter Connections Rate Description The total number of TCP connections per second, established during the last successful iteration performed in the search algorithm. The total number of HTTP requests sent by the clients in order to establish connections. The total number of HTTP requests received by the servers. The percentage of sent HTTP requests measured against the received HTTP requested. The total number of HTTP responses sent. The total number of HTTP responses received. The percentage of HTTP responses sent measured against the HTTP responses received. The number of bytes from all the http responses sent for each port The number of bytes from all the http responses received for each port. The total number of TCP SYN attack packets transmitted by all the users performing DoS attacks. The total number of TCP SYN attack packets forwarded by the DUT.
HTTP Requests Sent HTTP Requests Received HTTP Requests Completed Rate HTTP Responses Sent HTTP Responses Received HTTP Responses Completed Rate HTTP Response Bytes Sent HTTP Response Bytes Received Attack Packets Sent Attack Packets Passed

This section covers the following topics: Overview of the HTTP Transfer Rate Test on page 22-21. Test Cycle on page 22-21. Test Setup Parameters: Run Parameters on page 22-21. Pass/Fail Criteria on page 22-22. Test Results on page 22-22.
22-20
RFC 3511 Test Suite

Overview of the HTTP Transfer Rate Test
This test determines the transfer rate of HTTP requested object traversing the DUT. To measure it, there is used a set of HTTP client(s) configured to simultaneously initiate connections to the HTTP server(s). The measured average transfer rate of the DUT is referenced to all the objects successfully transferred across all the established connections. The test starts by connecting to the chassis and configuring the client and server networks you set for the test. The client network contains a set of http client(s) and the server network, a set of http server(s). Once the networks are configured, the test starts measuring the transfer rate. The measurements start on transmission of the first bit of the first requested object and end on transmission of the last bit of the last requested object. The http client(s) requests one or more objects from the http server(s). If multiple requests are intended, all have the same-sized object each time (the Response Object Size is a configurable parameter). If you want to test different object sizes, then multiple tests must be configured. A message displays warning you that the duration time for the test is at least equal with the value you specified for the Duration parameter. The average transfer rate of the firewall, expressed in bits per second, is calculated using the following formula:
TRANSFER RATE (BITS/SEC)= (COMPLETED_REQUESTS*RESPONSE_OBJECT_SIZE*8)/ (TOTAL_TRANSACTION_TIME)
Test Cycle
Each of these parameters are defined as follows: Completed_Requests represents the total number of objects successfully transferred across all connections. Response_Object_Size represents the object size expressed in bytes. For details about this parameter, see Run Parameters on page 22-7. Total_Transaction_Time represents the aggregate transfer time measured starting on transmission of the first bit of the first requested object and ending on transmission of the last bit of the last requested object.
If you specified more than one trial, the test restarts and each time the test repeats, it calculates the HTTP transfer rate. After each trial, the test collects statistics and then prints the results.
For more information about the common parameters see Run Parameters on page 22-7. For this test, take into account the note below in addition to the description of the Duration parameter:
NOTE: It is recommended that the Duration parameter be set to at least 100 seconds. A value lower than 100 is not allowed in the IxAutomate GUI.
22-21
22
RFC 3511 Test Suite

Pass/Fail Criteria
The pass/fail criteria available for this test are listed in Table 22-17 on page 2222.
Table 22-17. HTTP Transfer Rate - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The transfer rate, expressed in bits per second, that the DUT should be able to reach for each trial. Pass: The DUT reached the transfer rate equal to or greater than the value you entered. Fail: The DUT reached the transfer rate lower than the value you entered. Tolerance The tolerance value accepted for the transfer rate obtained in order to consider the result valid. Threshold = [1-(tolerance_value/100)*transfer_rate] Pass: If the obtained transfer rate is equal to or greater than the threshold value. Fail: If the obtained transfer rate is lower than the threshold value.
Target Transfer Rate
Test Results
Table 22-18 describes the HTTP Transfer Rate test results. Not all the statistics are available for one port. If the port is set to send requests, it cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics for both the HTTP requests sent and for the HTTP requests received.
Table 22-18. HTTP Transfer Rate - Test Results Parameter Transfer Rate HTTP Requests Sent HTTP Requests Received HTTP Responses Sent Description The value calculated for the transfer rate, expressed in bits per second. The total number of HTTP requests sent by each port set as client. The total number of HTTP requests received by each port set as server. The total number of HTTP responses sent by each port set as server.
22-22
RFC 3511 Test Suite

Maximum HTTP Transaction Rate Test
Table 22-18. HTTP Transfer Rate - Test Results Parameter HTTP Responses Received HTTP Bytes Number of Established TCP Connections Description The total number of HTTP responses received by each port set as client. The total number of bytes received for each port. The total number of TCP connections established during the test

This section covers the following topics: Overview of the Maximum HTTP Transaction Rate Test on page 22-23. Test Cycle on page 22-23. Test Setup Parameters: Run Parameters on page 22-24. Pass/Fail Criteria on page 22-24. Test Results on page 22-25.
Overview of the Maximum HTTP Transaction Rate Test
This test determines the maximum transaction rate the DUT can sustain. A transaction represents a request/response cycle. The test uses an iterative search algorithm to determine the maximum rate at which all transactions are completed. The test is intended to determine the maximum rate at which users can access objects. To achieve it, a set of http client(s) are configured to simultaneously initiate connections to the http server(s). The test starts by connecting to the chassis and configuring the client and server networks you set for the test. The client network contains a set of http client(s) and the server network, a set of http server(s). Once the networks are configured, the test starts the iterative search algorithm to determine the maximum http transaction rate the DUT can support. A message displays warning you that the duration time for sustaining the transactions is at least equal with the value you specified for the Duration parameter. The value you specified for the Initial HTTP Transaction Rate (per DUT) parameter represents the target value for the first iteration. Depending on this parameter, also including the search tolerance value in the result, the test determines the number of iterations necessary to reach the DUTs capacity. If the set value is higher than the number of transactions the DUT can reach, also including the tolerance value in the result, the test determines the number of performed transactions during the first iteration. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the maxi-
Test Cycle
22-23
22
RFC 3511 Test Suite

mum http transaction rate. After each trial, the test collects statistics and then prints the results. If the set value is lower than the number of transactions the DUT can perform, the test needs more than one iteration to determine the maximum transaction rate. Starting with the second iteration, the target value for the transaction rate is calculated using the binary search. When the value becomes higher than the DUTs capacity, including also the tolerance value in the result, the test determines the number of performed transactions. If you specified more than one trial, the test continues until all trials complete. After each trial the test collects statistics and then prints the results.
The algorithm continues its iterative search if the value of the maximum transaction rate achieved during the current iteration is in the following range or exceeds the upper limit: (target_value-search_tolerance; target_value). For example, if the search tolerance is set to 50 transactions and the maximum transaction rate reached is 1500, the result is considered valid if it is in the 14501500 range.
For more information about the common parameters see Run Parameters on page 22-7. For this test, take into account the note below in addition to the description of the Duration parameter:
NOTE: It is recommended that the Duration parameter be set to at least 30 seconds. It represents the time for which the DUT sustains the transaction rate. A value lower than 30 is not allowed in the IxAutomate GUI.
Table 22-19. Maximum HTTP Transaction Rate - Run Parameters Parameter Initial HTTP Transaction Rate (per DUT) Description Specify the total number of http transactions per second that you are expecting the DUT to reach over all the ports, during the first iteration of the iterative search algorithm. It represents the target value for the first iteration of each trial.
Pass/Fail Criteria
22-24
RFC 3511 Test Suite

Table 22-20. Maximum HTTP Transaction Rate - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The transaction rate that the DUT should be able to reach. You can select either of the two methods to calculate the transaction rate: Average/Port: The test averages the transaction rates over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest transaction rates measured on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT reached the transaction rate equal to or greater than the value you entered. Fail: The DUT reached the transaction rate lower than the value you entered.
Target Transaction Rate
Test Results
Table 22-21 describes the Maximum HTTP Transaction Rate test results. Not all the statistics are available for one port. If the port is set to send requests, it cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics for both the HTTP requests sent and for the HTTP requests received.
Table 22-21. Maximum HTTP Transaction Rate - Test Results Parameter Max HTTP Transaction Rate Aggregated Transaction Rate Transaction Rate (%) HTTP Requests Sent HTTP Requests Received HTTP Responses Sent Description The maximum HTTP transaction rate performed on each port during the last successful iteration performed in the search algorithm. The average value for the transaction rates performed over all the ports during the last successful iteration performed in the search algorithm. The percentage of performed transaction rate measured against the expected transaction rate. The total number of HTTP requests sent by each port set as client in order to establish connections. The total number of HTTP requests received by each port set as server. The total number of HTTP responses sent by each port set at server.
22-25
22
RFC 3511 Test Suite

Illegal Traffic Handling Test
Table 22-21. Maximum HTTP Transaction Rate - Test Results Parameter HTTP Responses Received HTTP Response Bytes Received Description The total number of HTTP responses received by each port set as client. The total number of bytes received for each port.

This section covers the following topics: Overview of the Illegal Traffic Handling Test on page 22-26. Test Cycle on page 22-26. Test Setup Parameters: Run Parameters on page 22-27. Pass/Fail Criteria on page 22-28. Setting Up the DUT on page 22-29. Test Results on page 22-29.
Overview of the Illegal Traffic Handling Test
This test determines the behavior of the DUT when presented with a combination of both legal and illegal traffic. The illegal traffic does not refer to an attack, but to the traffic which has been explicitly defined by the rule(s) to drop. An iterative search algorithm is used to determine the maximum connection rate at which the firewall can handle the packets. To achieve it, a set of http client(s) are configured to simultaneously initiate connections to the http server(s). Two connections type are set to be established during the test: 1. The HTTP TCP connections on port 80 (it represents the default port for legal traffic) 2. The connections initiated from the port you set as Blocked Port (it represents the port for illegal traffic)
Test Cycle
The test starts by connecting to the chassis and configuring the client and server networks you set for the test. The client network contains a set of http client(s) and the server network, a set of http server(s). The clients offer the connection requests both for legal and illegal traffic. Once the networks are configured, the test starts the iterative search algorithm to determine the maximum connections rate the DUT can sustain. The value you specified for the Expected Connections Rate parameter represents the target value for the first iteration. Depending on this parameter, also including the search tolerance value in the result, the test determines the number of iterations necessary to reach the DUTs capacity.
22-26
RFC 3511 Test Suite

If the set value is higher than the number of connections the DUT can perform, also including the tolerance value in the result, the test determines the number of established connections during the first iteration. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the maximum connections rate. After each trial, the test collects statistics and then prints the results. If the set value is lower than the number of connections the DUT can perform, the test needs more than one iteration to determine the maximum connections rate. Starting with the second iteration, the target value for the connection rate is calculated using the binary search algorithm. When the value becomes higher than the DUTs capacity, including also the tolerance value in the result, the test determines the number of performed connections. If you specified more than one trial, the test continues until all trials complete. After each trial, the test collects statistics and then prints the results.
The algorithm continues its iterative search if the value of the maximum connections rate achieved during the current iteration is in the following range or exceeds the upper limit: (target_value-search_tolerance; target_value). For example, if the search tolerance is set to 100 connections and the maximum connections rate reached is 1500, the result is considered valid if it is in the 14001500 range or exceeds the 1500 value.
For more information about the common parameters see Run Parameters on page 22-7. Table 22-22 on page 22-27 and Table 22-23 on page 22-28 list the run parameters that are different from the standard settings or unique for this test.
Table 22-22. Illegal Traffic Handling - Test Parameters Parameter Expected Connections Rate Description Specify the total number of connections per second that you are expecting the DUT to reach over all the ports during the first iteration of the iterative search algorithm. It represents the target value for the first iteration of each trial.
Table 22-23 lists the forwarding rules that you can set for this test.
22-27
22
RFC 3511 Test Suite

Table 22-23. Illegal Traffic Handling - Forwarding Rules Parameter Source of Illegal Traffic Blocked Port Description The network source for the illegal traffic. You have to set as source of illegal traffic one of the Client Networks you have defined for your test. The TCP port number for illegal traffic. The firewall is configured to drop traffic with this TCP port number. The port for illegal traffic should have a value inside the following range: (1;65365), excepting the value 80 which represents the default port, set for the legal traffic (the HTTP TCP connections). Approximate Illegal Traffic Ratio Illegal traffic, as a percentage of the total traffic sent.
Pass/Fail Criteria
The pass/fail criteria available for this test are listed in Table 22-24 on page 2228.
Table 22-24. Illegal Traffic Handling - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of connections per second that the DUT should be able to establish. You can select either of the two methods to calculate the establishment connection rate: Average/Port: The test averages the number of connections established over all ports, for the best iteration, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest number of established connections measured on each port, for the best iteration, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT established a number of connections equal to or greater than the value you entered. Fail: The DUT established a number of connections lower than the value you entered.
Connections Rate
22-28
RFC 3511 Test Suite

Setting Up the DUT
The forwarding rules should be set on the DUT interface that corresponds to the Client Network you set as source of illegal traffic. To set up the forwarding rules for your DUT: 1. Configure the DUT for 10% less than the maximum number of rule sets the system supports. 2. The rule sets can be configured based on source IPs, destination IPs and application layer protocol fields. All the parameters in these rule sets do not match the parameters of the generated traffic, as configured in the test. 3. In addition to the above, configure two more rule sets based on two types of network traffic. These rule sets match the test traffic that is forwarded/ dropped by the DUT. 4. Configure the test to request pages based on the two rule sets configured on the DUT. The rules on the DUT should be based on the TCP ports. NOTE: The TCP ports must be the same in the test configuration and in the DUT configuration. If you configure the test first, when configuring the DUT be sure to set exactly the same TCP ports.
Test Results
Table 22-25 describes the Illegal Traffic Handling test results. Not all the statistics are available for one port. If the port is set to send requests, it cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics both for the HTTP requests sent and for the HTTP requests received.
Table 22-25. Illegal Traffic Handling - Test Results Parameter Connections Attempted Legal Connection Rate (conn/sec) Legal HTTP Requests Sent Legal HTTP Requests Received Legal HTTP Responses Sent Legal HTTP Responses Received Legal HTTP Bytes Received Illegal Connections Attempted Description The number of connections per second you are expecting the DUT to establish. The number of legal connections per second performed by the DUT. The total number of legal HTTP requests sent by each port set as client in order to establish connections. The total number of legal HTTP requests received by each port set as server. The total number of legal HTTP responses sent by each port set as server. The total number of legal HTTP responses received by each port set as client. The total number of HTTP bytes received by each port set as server. The number of illegal connections per second attempted.
22-29
22
RFC 3511 Test Suite

IP Fragmentation Handling Test
Table 22-25. Illegal Traffic Handling - Test Results Parameter Legal Connections Attempted Illegal HTTP Connections Attempted (%) Description The number of legal connections per second attempted. The illegal HTTP connections attempted as a percentage of the total HTTP connections initiated. The illegal traffic represents the traffic which has been explicitly defined by a rule to be dropped. The number of SYN packets allowed by the DUT from the illegal traffic over all the ports.
Illegal SYN Packets Received

This section covers the following topics: Overview of the IP Fragmentation Handling Test on page 22-30. Test Cycle on page 22-31. Test Setup Parameters: Run Parameters on page 22-32. Pass/Fail Criteria on page 22-33. Test Results on page 22-33.
Overview of the IP Fragmentation Handling Test
This test determines the performance impact when the DUT is presented with IP fragmented traffic. IP packets which have been fragmented due to crossing a network that supports a smaller MTU (Maximum Transmission Unit) than the actual IP packet may require the firewall to perform re-assembly before the rule set is applied. The test focuses on determining the percentage of fragmented traffic forwarded by the DUT to the receiving ports. Also, it measures the performance deterioration when additional processing with the re-assembly of the packets is introduced.
22-30
RFC 3511 Test Suite

As specified in RFC 3511, two types of traffic are generated: HTTP traffic as non-fragmented traffic and UDP or IP fragmented packets.
These two types of traffic cannot coexist on the same port. This is why this test requires at least four ports: two ports for non-fragmented traffic (transmitting port and receiving port) and two ports for fragmented packets (transmitting port and receiving port).
Test Cycle
The test starts by connecting to the chassis and configuring the client and server networks you set, first for the fragmented traffic, and secondly, the networks you set for the non-fragmented traffic. The client network contains a set of http client(s) and the server network a set of http server(s). Also, the ARP requests are sent at the beginning of the test. Once the networks are configured, the test starts transmitting simultaneously the two types of traffic: the HTTP traffic as non-fragmented traffic and the UDP/IP packets as fragmented traffic. The measurements for the HTTP transfer rate start on transmission of the first bit of the first requested object and end on transmission of the last bit of the last requested object. The test does not use an iteration search algorithm to determine the transfer rate and it may include more than one trial (the Number of Trials is a configurable parameter), but not more than one iteration. When sending the two types of traffic, the following procedure is used: For the non-fragmented traffic: each HTTP client requests one or more objects from an HTTP server using one or more HTTP requests over each connection. If multiple requests are intended, all have the same-sized object each time (the Response Object Size is a configurable parameter). If you want to test different object sizes, then multiple runs of the test are needed. For the fragmented traffic: a test instrument attached to the unprotected side of network offers a unidirectional stream of unicast fragmented IP/UDP traffic, targeting a server attached to the protected side of network.
The average transfer rate of the firewall, expressed in bits per second, is calculated using the following formula:
TRANSFER RATE (BITS/SEC)= (COMPLETED_REQUESTS*RESPONSE_OBJECT_SIZE*8)/ (TOTAL_TRANSACTION_TIME)
Each of these parameters are defined as follows: Completed_Requests represents the total number of objects successfully transferred across all connections. Response_Object_Size represents the object size, expressed in bytes. For details about this parameter, see Run Parameters on page 22-7.
22-31
22
RFC 3511 Test Suite

Total_Transaction_Time represents the aggregate transfer time measured starting on transmission of the first bit of the first requested object and ending on transmission of the last bit of the last requested object.
If you specified more than one trial for the test, it restarts and each time the test repeats, it calculates the HTTP transfer rate. After each trial, the test collects statistics and prints the results.
For more information about the common parameters see Run Parameters on page 22-7. For this test, add the note below to the description of Duration parameter:
NOTE: It is recommended that the Duration parameter be set at least to 20 seconds. It represents the time for which the DUT transmits traffic effectively.
Table 22-26. IP Fragmentation Handling Test - Run Parameters Parameter Description
Fragmented Traffic Parameters Full Packet Size (bytes) The maximum number of bytes the UDP/IP packet should contain, excluding the bytes associated with the HTTP header. For testing purposes, this parameter can be configured to values smaller than the MTU supported by the link layer. Maximum transmission unit, expressed in bytes, which can be supported by the configured networks. The packets larger than the MTU value are fragmented in order to be transmitted. The percentage of media utilization by the fragmented type of traffic. The tolerance for the forwarded fragments as a percentage of the total traffic forwarded in order to consider the result valid. The default value is 0%.
MTU (bytes)
Intended Line Load (%) Forwarded Fragments Allowed (%)
Traffic Type Configuration Network For each of the configured networks, both client and server, you can choose the traffic type. In this parameter field, you can select the network. For the network set in the Network field parameter you can select the traffic type. The available options are: HTTP 1.1 Fragmented IP/UDP NOTE: At least one pair of client and server networks must be configured, for each type of traffic. These configuration elements are verified at runtime, and if they do not exist, an error message displays and the test does not run.
Traffic Type
22-32
RFC 3511 Test Suite

Pass/Fail Criteria
Table 22-27. IP Fragmentation Handling - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
Passed Fragments(%) The percentage of fragmented traffic accepted to be forwarded by the DUT in order to consider the result valid. This may be considered the tolerance for the fragmented traffic. Pass: The percentage of fragmented traffic was lower than or equal to the value you specified. Fail: The percentage of fragmented traffic exceeded the value you specified.
Test Results
Table 22-28 on page 22-33 describes the IP Fragmentation Handling test results. Not all the statistics are available for one port. If the port is set to send requests, it cannot send responses, it can only receive responses. For example, you cannot have for the same port statistics both for the HTTP requests sent and for the HTTP requests received.
Table 22-28. IP Fragmentation Handling - Test Results Parameter Tx Count (fragmented packets) Rx Count (fragmented packets) Percent Forwarded Fragments Transfer Rate HTTP Requests Sent HTTP Requests Received HTTP Responses Sent Description The total number of fragmented packets sent. The total number of fragmented packets received. The forwarded fragments as a percentage of the total traffic forwarded. The value calculated for the transfer rate, expressed in bits per second. The total number of HTTP requests sent by each port set as client in order to establish connections. The total number of HTTP requests received by each port set as server. The total number of HTTP responses sent by each port set as server.
22-33
22
RFC 3511 Test Suite

Latency Test
Table 22-28. IP Fragmentation Handling - Test Results Parameter HTTP Responses Received Description The total number of HTTP responses received by each port set as client.
HTTP Bytes Received The total number of bytes received for each port.
Latency Test
This section covers the following topics: Overview of the Latency Test on page 22-34. Test Cycle on page 22-34. Test Setup Parameters: Run Parameters on page 22-35. Pass/Fail Criteria on page 22-37. Test Results on page 22-37.
Overview of the Latency Test
This test determines the latency of network-layer or application-layer data traversing the DUT. Latency reveals how much processing overhead the DUT requires to forward frames, when choosing the network layer traffic, or how much processing overhead the DUT requires to sustain connections, when choosing the application layer traffic. The latency is to be determined in two different ways, depending on the traffic type you choose: For application layer data, the test uses an incremental search algorithm to determine the latency measurements at throughput level. To determine it, a set of http client(s) are configured to initiate connection(s) to the http server(s). The throughput level represents the value at which the DUT can forward all the requests, it receives with no exception. For network layer data, the test uses the per port binary search algorithm to determine the latency measurements at throughput level. The throughput level means the highest rate at which the DUT can forward frames with no frame loss.
Test Cycle
The test starts by connecting to the chassis and configuring the client and server networks you set for the test. At application layer, the client network contains a set of http client(s) and the server network, a set of http server(s). At network layer, the client network contains a set of client(s) and the server network contains a set of server(s). Once the networks are configured, the test starts the algorithm in order to determine the latency. Depending on the traffic type you choose, the test continues in a different way: If you choose the application-layer traffic type, the http client(s) request one or more objects from the http server(s). If multiple requests are intended, all
22-34
RFC 3511 Test Suite

Latency Test
of them have the same-sized object each time (the Response Object Size is a configurable parameter) during a test cycle. You have to set different tests if you want to test different object sizes. The test determines the latency value at the throughput level, so the DUT tries to reach first the maximum level of throughput according to the configuration and then measures the latency. The value specified for the Maximum Expected Throughput parameter influences the result as follows: If the value is higher than the DUTs capacity, the measured latency displays as result; If the value is smaller than the DUTs capacity, the result is equal with the delay recorded at the specified throughput level reached. Each time the test repeats, it determines first the throughput and then measures the latency. If you specified more than one trial, the test continues until all trials complete. After each trial, the test collects statistics and then prints the results. If you choose the network-layer traffic type, the http client(s) offer a unidirectional stream of unicast packets to the http server(s). The packets use the IP/ UDP protocol and you can specify their frame size. The test transmits frames (the size is specified by Frame Size) from the client ports to the server ports. After transmitting all the frames, the test allows two seconds for additional frames to come in, then it collects the statistics for the throughput and latency. The binary search algorithm is used to determine the DUT throughput. The test determines the latency value at the throughput level, so the DUT tries to reach first the maximum level of throughput according to the configuration and then measures the latency. If you specified more than one trial, the test restarts, using the same frame size. Each time the test repeats, it calculates the DUT throughput and measures the latency at the determined throughput level. After all trials for that frame size are complete, the test either ends or, if you specified more than one frame size, it restarts with the next largest frame size. After each trial, the test collects statistics and then prints the results. The test continues until all trials and frame sizes are complete. To obtain an accurate result, it is recommended to run the test with different frame sizes.
For more information about the common parameters see Run Parameters on page 22-7. For this test, add the following note to the description of Duration parameter:
NOTE: It is recommended that the Duration parameter be set at least to 30 seconds. It represents the minimum time for each trial.
Table 22-29, Table 22-30 and Table 22-31 on page 22-36 list the run parameters that are different from the standard settings or unique for this test.
22-35
22
RFC 3511 Test Suite

Latency Test
Table 22-29. Latency Test - Run Parameters Parameter Calibrate Latency Description If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10.
Table 22-30 describes the run parameters you must set when choosing the application layer traffic.
Table 22-30. Latency Test - Application Layer Run Parameters Parameter Maximum Expected Throughput (MB/s) Description Specify the value for the throughput, expressed in megabytes per second, which you are expecting the DUT to reach during the incremental search algorithm. It represents the value at which the latency is to be measured. The throughput represents the value at which the DUT can forward all the requests that it receives, with no loss.
Table 22-31 on page 22-36 describes the run parameters you must set when choosing the network layer traffic:
Table 22-31. Latency Test - Network Layer Run Parameters Parameter Frame Size Description Three modes for selecting frame sizes are available: The standard mode uses a list of frame sizes defined by RFC 2544. NOTE: The minimum frame size available for this test is 80, not 64, as indicated in the graphical interface. When running a test, a warning message displays containing information about this. The automatic mode uses a range of frame sizes which you define and increments them by a value which you can select as well. Manual mode allows you to define your own frame sizes. For more information about how to select the frame sizes, see Chapter 3, Choosing Frame Sizes.
22-36
RFC 3511 Test Suite

Latency Test
Pass/Fail Criteria
Table 22-32. Latency Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of the two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Latency
Test Results
Table 22-33 describes the Latency test results available for the tests that use the application layer traffic. The statistics are available only for the ports set as sending ports.
Table 22-33. Latency Test Results - Application Layer Traffic Parameter Throughput (MB/s) Connection Time Description The throughput value, expressed in megabytes per second (MB/s), obtained during the test. Average time elapsed, expressed in milliseconds (ms), between the time the client sends a packet and the time it receives the response to that packet. Average time elapsed, expressed in milliseconds (ms), before clients receive the first byte of an http response. Average time elapsed, expressed in milliseconds (ms), before clients receive the last byte of an http response. The time difference between the Time to first byte and the Time to last byte, expressed in milliseconds (ms).
Time to First Byte Time to Last Byte Average Transit Time
22-37
22
RFC 3511 Test Suite

Latency Test
Table 22-34 describes the Latency results available for the tests that use the network layer traffic. The statistics are available only for the ports set as sending ports.
Table 22-34. Latency Test Results - Network Layer Traffic Parameter Average Latency Minimum Latency Maximum Latency TxTput (%) TxTput (pps) Description The mean of all measurements of latency recorded by data traversing the DUT. The smallest latency value recorded by data traversing the DUT. The longest latency value recorded by data traversing the DUT. Transmit throughput, as a percentage of the theoretical maximum port speed. Transmit throughput, in packets per second (pps).
22-38
23
Chapter 23:
LACP Test Suite
This chapter covers the following topics: Overview of the LACP Test Suite on page 23-1. Setting Up the Tests on page 23-2. Port to LAG Throughput Test on page 23-13. LAG to LAG Throughput Test on page 23-17. LAG to LAG Link Drop Test on page 23-21.
Overview of the LACP Test Suite

The Link Aggregation Control Protocol (LACP) is described by IEEE standard 802.3ad for dynamically exchanging configuration information among cooperating systems in order to automatically configure and maintain link aggregation groups. The protocol can automatically detect the presence and capabilities of other aggregation capable devices (for example, by using the LACP protocol, it is possible to specify which links in a system can be aggregated). The Ixia link aggregation test offers a functional, scalability, and throughput test suite. The LACP test suite provides both data plane and control plane testing. It terminates aggregated ports from a switch or a router and measures the throughput, latency, and dropped frames counts. In addition, it performs functional testing by allowing you to bundle several physical ports together to form a single logical channel manually or automatically, by sinking or sourcing LACP controlled ports. IxAutomate includes the following tests for the LACP protocol: LACP Port to LAG Throughput Test determines the maximum rate at which the DUT receives, processes and forwards frames with loss lower than or equal to the specified value for loss tolerance. The traffic is bidirectional and a one-to-one logical mapping is used, that is, an individual Ixia port maps to an Aggregated Link (LAG group). Physically, a one-to-many traffic mapping routine is required. The test also measures the latency, if you choose to do this.
23-1
23
LACP Test Suite

LACP LAG to LAG Throughput Test measures the highest rate at which the DUT receives, processes and forwards frames with loss lower than or equal to the specified value for loss tolerance. The traffic is bidirectional and a one-toone logical mapping is used: an Aggregated Link (LAG group) maps to another Aggregated Link (LAG group). Physically a many-to-many traffic mapping routine is required. The test measures also the latency, if you choose to do this. LACP LAG to LAG Link Drop Test determines the number of dropped frames when a port becomes unavailable. The traffic is bidirectional and a one-to-one logical mapping is used: an Aggregated Link (LAG group) maps to another Aggregated Link (LAG group). Physically, a many-to-many traffic mapping routine is required. The test also measures the latency, if you choose to do this.

Most of the LACP tests parameters are common to many IxAutomate tests and work the same way for all of them. Each test description includes a description of the parameters, which are unique for that test. For the common Run Parameters see Run Parameters on page 23-10. The other parameters are described as follows: Protocols: The LACP tests use MAC addressing and IPv4/v6 addressing. For the MAC Protocol parameters, see Configuring MAC Addresses on page 319; for the IP Protocol parameters, see Configuring IP Addresses on page 325. For information about the parameters that are different from the standard settings for these tests, see Protocol Parameters on page 23-6. Frame Sizes: The LACP tests require that you define the frame size of the IP traffic used by the test to test the DUT. For information about frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. For information about the parameters that are unique for these three tests, see Traffic Setup Parameters on page 23-2. Protocol Parameters on page 23-6. Run Parameters on page 23-10.
You can use the Traffic Map area of the Traffic Setup window to set up a traffic map for your test. The available controls depend on whether you are creating an Automatic map or a Manual map. If you choose to automatically create a map, only one or two aggregated link groups can be defined (the second LAG is optional for the Port to LAG throughput test). For each LAG, the ports that aggregate into a link must be supplied. For the Port to LAG Throughput test, assuming that no ports are excluded (Figure 23-1):
23-2
LACP Test Suite

The logical one-to-one generated map would be Port 1.2.1 to First LAG and Port 1.3.1 to Second LAG. The first LAG contains three ports, 1.1.1, 1.1.2, 1.1.3 and the Second LAG contains two ports, 1.2.2 and 1.2.3.
Figure 23-1. LACP Tests - Automatic Map (Port to LAG)
For the LAG to LAG Throughput test and LAG to LAG Link Drop test, assuming that no ports are excluded (Figure 23-2): The first LAG contains two ports: 1.2.1 and 1.2.2; the second LAG contains two ports: 1.2.3 and 1.2.4.
Figure 23-2. LACP Tests - Automatic Map (LAG to LAG)
If you enable the Passive LACP Participation option, available for each LAG, then the DUT initiates the LACP connection with the Ixia ports. If you choose to create a manual map, only the Direction parameter for sending traffic remains enabled in the Traffic Map section. To set the manual map, click the Configure button and the Configure LAG mappings dialog opens (Figure 233). For the LAG to LAG Throughput test and the LAG to LAG Drop Link test, the defined LAGs (Figure 23-4 on page 23-4) are listed as well in the left pane.
23-3
23
LACP Test Suite

Figure 23-3. LACP Tests - Manual Map (Port to LAG)
Figure 23-4. LACP Tests - Manual Map (LAG to LAG)
To create a manual map: 1. Define one or more link aggregation groups. At least one LAG must be defined to be able to run a test for the Port to LAG throughput test and at least two LAGs must be defined for the other two tests in order to be able to run a test. For more details on how to create a LAG, see To Define a LAG: on page 23-5.
23-4
LACP Test Suite

2. Create your traffic map by choosing a correspondence between a port/LAG from the Source Port pane and a LAG from the Destination LAG pane. For more details, see Mapping one Port/LAG to one LAG: on page 23-5.
To Define a LAG:
1. Set the basic LAG parameters fields: LAG Name, LAG ID (the LAG MAC), LACP Participation and LACP Timeout. 2. Click the Add LAG button and a new empty LAG-<number> label is added into the LAG tree. It is automatically selected (it appears against a blue background). 3. Select the ports from the left pane that are to be aggregated in the current LAG. You can select multiple ports at once for the selected LAG. 4. Click the add-ports-to-selected LAG (+>>) button and the selected ports are added into the LAG. 5. If you want to add more ports for a LAG, then select the LAG and repeat steps 3 and 4. In a LAG definition, the following settings can be changed later on, after selecting the appropriate LAG from the tree: The basic parameters can be modified in the frame where they were first defined. You can remove the ports from a LAG if you select the port and then click the remove-ports-from-LAG (<<-) button. The ports removed from the LAG are then available in the left pane for any other link aggregation group. The selected LAG can be deleted by clicking the Rem LAG button. The ports contained in this LAG are then available in the left pane for any other link aggregation group.
NOTE: When closing the window after defining the LAGs, if there are any LAGs without associated ports, they are not saved.
Mapping one Port/LAG to one LAG:

1. From the left pane (Source Port) select: For Port to LAG: one of the available ports (one of the non-aggregated ports) or For LAG to LAG: one LAG from the available LAGs. 2. Select one of the defined LAGs (a valid one, which contains ports) from the middle pane (Destination LAG). 3. Click the +>> button available in the left side of the Configured Maps pane. The map appears in the Configured Maps pane and the selected port/LAG and LAG are now disabled. From this point on, the LAG properties cannot be changed (the LAG is now defined in a traffic map).
23-5
23
LACP Test Suite

Protocol Parameters
Both for the Automatic and the Manual modes, the Random MAC Addresses check box is available for all L2/3 protocols. If you enable it, the MAC addresses are randomly assigned to the ports and all the parameters that allow you to set the MAC addresses become unavailable. For the Automatic mode, the LAGs are treated like ordinary ports in VLAN Settings and L2/3 Protocol and L4 Protocol assignment. The distribution of addresses and tags is made respecting the defined traffic map, sorted by Tx ports (individual links): assign incrementing addresses for the first ports interfaces; meanwhile assign the VLAN tags and increment them accordingly. The same procedure is applied to the Rx LAG associated to the first Tx port. This procedure is applied for each defined match. The TCP/UDP port can be defined and it can be incremented to provide the DUT with criteria for conversation recognition. For the Manual mode, the following are unique for these tests (Figure 23-5 on page 23-7): LAGs are added at the top of the tree and accept settings just like any other port Aggregated ports are moved into their LAG and they are disabled. They do not accept distinct settings. The MAC Address, Increment MAC Address, Increment IPv4/v6 Address, TCP/UDP Port, and Increment TCP/UDP Port parameters may be used by the LACP algorithm to identify conversations (frames should arrive in order from source to destination for the same conversation). The VLANs parameters may be used by the LACP algorithm to enable the outer VLAN tag and to enable the inner VLAN tag (Stacked VLAN (Q in Q)): For the outer VLAN, you may set the VLAN ID and the No. of addresses; For the stacked VLAN, you can define the Inner VLAN ID and the Increment Inner VLAN ID.
23-6
LACP Test Suite

Figure 23-5. Per Port Settings
Specific Parameters
Table 23-1 lists the specific parameters defined for the LACP tests. They are available only for the Automatic mode.
Table 23-1. Parameter Addresses per Port (LAG) First MAC Address Increment MAC (switch emulation) LACP Tests - Specific Parameters Description Allows you to set the number of addresses that you want to define per LAG. Allows you to define the first MAC address. If you check this box, the test increments the MAC address it assigns for each interface in a LAG. If you do not check this box, all the interfaces in a LAG have the same MAC address.
23-7
23
LACP Test Suite

Layer 4 Protocol Parameters

Table 23-2 lists the Layer 4 protocol available for the LACP tests.
Table 23-2. Parameter L4 Protocol LACP Tests - L4 Protocol Parameters Description You can choose one of the following options: None TCP UDP First L4 Port Increment TCP/UDP Port This allows you to set the first port for the layer 4 protocol. If you check this box, the test increments the value that you specified for First L4 port for the layer 4 ports used in your test.
IMPORTANT: When Manual mode is set, only the L4 Protocol parameter can be set.
VLAN Settings Parameters

Table 23-3 lists the VLAN parameters that are available for the LACP tests, for the Automatic mode.
Table 23-3. Parameter LACP Tests - VLAN Parameters Description
Enable VLAN Settings Applies the outer VLAN settings. First Vlan ID The first VLAN tag to be assigned. For more information, see Setting the VLAN Parameters on page 3-42. If you check this box, the test increments the VLAN tag assigned to each LAG. For example, if you define two LAGs: all the addresses from LAG 1 have the VLAN ID=111 all the addresses from LAG 2 have the VLAN ID=112 If you do not check this box, traffic from every LAG has the same VLAN ID.
Increment ID between Ports (LAGs)
23-8
LACP Test Suite

LACP Tests - VLAN Parameters (Continued) Description If you check this box, the test increments the VLAN tag that it assigns to addresses inside a LAG. For example, if you define two LAGs with three addresses for each LAG, the VLAN IDs are: LAG 1: address 1=111, address 2=112, address 3=113 LAG 2: address 1=111, address 2=112, address 3=113 If you do not check this box, traffic from every LAG has the same VLAN ID.
Increment ID between Port Addresses
Enable stacked VLAN (Q in Q) First Inner VLAN ID
Applies the inner VLAN settings. The first inner VLAN tag to be assigned
Increment Inner ID If you check this box, the test increments the inner between Ports (LAGs) VLAN tag assigned to each LAG. For example, if you define two LAGs: all the addresses from LAG 1 have the inner VLAN ID=222 all the addresses from LAG 2 have the inner VLAN ID=223 If you do not check this box, traffic from every LAG has the same inner VLAN ID. Increment Inner ID between Port Addresses If you check this box, the test increments the inner VLAN tag that it assigns to addresses inside a LAG. For example, if you define two LAGs with three addresses for each LAG, the inner VLAN IDs are: LAG 1: address 1=222, address 2=223, address 3=224 LAG 2: address 1=222, address 2=223, address 3=224 If you do not check this box, traffic from every LAG has the same inner VLAN ID.
If the two Increment parameters are enabled at the same time (for both outer and inner VLANs), the following behavior is noted: For example, if you define two LAGs with three addresses for each LAG, the test assigns the following VLAN IDs: LAG 1: address 1=111, address 2=112, address 3=113 LAG 2: address 1=114, address 2=115, address 3=116
23-9
23
LACP Test Suite

Run Parameters
Table 23-4 lists the common run parameters for the LACP tests.
Table 23-4. Parameter Duration LACP Tests - Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. This allows you to choose if you want to calculate the latency or not for your test. You can choose one of the following options: None it means that you do not want to calculate the latency value for your test Cut-Through you choose to calculate latency using the Cut Through method: that is, the delay between the time the first bit of the test frame leaves the Ixia TX port and the time it arrives on the Ixia RX port. Cut Through is normally used with switches and other devices that operate using packet header information. 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 you choose to calculate latency using the Store and Forward method: that is, the delay between the time the last bit of the test frame leaves the Ixia TX port and the time its first bit arrives on the Ixia RX port. Store and Forward is normally used with routers and other devices that operate on the contents of the entire packet. The last transmitted data bit 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 latency is calculated by first determining the Cut Through delay and then substracting the frame length time. Inter-Arrival Time you can choose to calculate latency using the Inter-Arrival Time method: that is, the time between packet arrivals are compared. In this case, when a packet is received, the timestamp of the previous packet is subtracted from the current timestamp. The interval between the timestamps is the jitter, and it is recorded for statistical purposes.
No. of Trials
Latency Calculation
23-10
LACP Test Suite

LACP Tests - Run Parameters (Continued) Description If you check this box, the DUT complies with the requirement to send the packets of a conversation in order. The following additional test results are available if this option is enabled: Small Sequence Errors it represents the number of times when the current sequence number minus the previous sequence is less than or equal to 2. Big Sequence Errors it represents the number of times when the current sequence number minus the previous sequence is greater than or equal to 2. Reverse Sequence Errors it represents the number of times when the current sequence number is less than the previous sequence number. Total Sequence Errors it represents the sum of the small, big, and reverse sequence errors.
Sequence Checking
Staggered Transmit
Uniform Traffic
If it is enabled (by default, it is enabled), the transmit rate on all Tx ports is the same. The rate is equal to the percentage value applied on the port with the lowest throughput capabilities. If it is not enabled, each Tx port transmits at a different rate. Each rate is equal to the percentage value applied to its own throughput capability. IMPORTANT: This option is available only when the Load Rate parameter is expressed in percents. When it is set to kilobits per second (kb/s) or frames per second (f/s), this option is not available.
Calibrate Latency
23-11
23
LACP Test Suite

LACP Tests - Run Parameters (Continued) Description This allows you to choose the algorithm that you want to use to calculate the throughput. It determines how the search algorithm searches for a new rate. You can select one of the following options: Binary the initial rate should be set to the theoretical maximum. a: If you choose Per-Port, the binary search algorithm searches each LAG pair separately. A rate change on one port does not affect the others. b: If you choose Linear, the binary search algorithm searches all LAG pairs together, as a group. A rate change applies to all LAG pairs Linear the initial rate should be set under the expected maximum and the step size should reflect the desired resolution.
Search Type
Loss Tolerance
The percentage of transmitted frames that can be lost before frame loss is declared. IxAutomate calculates loss according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Load Rate (%)
Specify the starting rate at which frames are transmitted. Load is applied to the DUT by transmitting frames at a rate in terms of: kilobits per second (kb/s) percentage of the maximum frame rate (%) frames per second (f/s). Use caution when specifying low rates; the test can become less accurate if, for example, the frame rate nears 1 frame per second (f/s).
Increment
Specify the increase (positive value) or decrease (negative value) in the transmit rate for each new iteration. This allows you to choose how to print the output results in order to observe the traffic distribution. You can select one of the following options: Per Flow the results aggregation shows the traffic distribution per flow. Per Port the results aggregation shows the traffic distribution among ports.
Statistics Aggregation
23-12
LACP Test Suite

Port to LAG Throughput Test

This section covers the following topics: Overview of the Port to LAG Throughput Test on page 23-13. Test Cycle on page 23-13. Test Setup: Run Parameters on page 23-14. Pass/Fail Criteria on page 23-14. Test Results on page 23-16.
Overview of the Port to LAG Throughput Test
This test determines the maximum rate at which the DUT receives, processes, and forwards the frames without any frame loss. This test uses a one-to-one logical mapping: an individual Ixia port maps to an Aggregated Link (LAG group). Physically, a one-to-many traffic mapping routine is required. The aggregated link emulates a switch trunk port or multiple server NIC cards. Bidirectional traffic to/from the aggregated link from/to each individual port is generated and analyzed. An individual port transmits traffic at a predefined rate, as the traffic reaches the DUT, it is processed by the DUT's load balancing routine for the LAG Group (LACP channel). The traffic is then fanned out onto each of the groups physical ports and the Ixia ports receive the traffic.
Test Cycle
The test starts by connecting to the chassis, configuring the ports that you set, and installing the LACP protocol per each aggregated port at the beginning of the test. Then the LAG is started on all ports. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports. The binary or the linear search algorithm is used to find out and calculate the DUT throughput. Additionally, the latency can be calculated for the test. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the DUTs throughput. Each trial runs with all the frame sizes that you set for your test. After all the trials complete, the test ends. It is recommended to perform the throughput measurements with different frame sizes. When testing with different frame sizes, the DUT configuration should remain the same. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost frames. After gathering statistics, it prints the results.
23-13
23
LACP Test Suite

For more information about the common run parameters, see Run Parameters on page 23-10. For information about the common settings for the LACP tests, see Setting Up the Tests on page 23-2. For information about other tests in this family, see LACP Test Suite on page 231. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass/Fail Criteria

Table 23-5. Parameter Pass Criteria LACP Port to LAG Test Pass/Fail Parameters Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
23-14
LACP Test Suite

LACP Port to LAG Test Pass/Fail Parameters (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Amount of time required by the DUT to forward frames. To specify the unit of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port (LAG): The test averages the latency over the port (LAG), then applies the criteria to determine whether a trial passed or failed. Maximum Port (LAG): The test selects the longest latency experienced on each LAG, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
23-15
23
LACP Test Suite

Test Results
Table 23-6 describes the LACP Port to LAG test results. These are available per flow or per port.
Table 23-6. Result TxCount RxCount Tx Tput (f/s) Tx Tput (%) Frame Loss Frame Loss (%) LACP Port to LAG Test Results Description Total number of transmitted frames Total number of received frames Throughput expressed in terms of frames per second (f/s) Throughput expressed as a percentage of the theoretical maximum rate frame The number of lost frames when the network is in the process of reaching the throughput The number of lost frames, expressed as a percentage, when the network is in the process of reaching the throughput
If you choose to calculate the latency for your test, the following test results are available: MinLatency (ns) MaxLatency (ns) AvgLatency (ns)
If you enable the Sequence Checking box, the following additional test results become available: Small Sequence Errors the number of times when the current sequence number minus the previous sequence is less than or equal to 2. Big Sequence Errors the number of times when the current sequence number minus the previous sequence is greater than or equal to 2. Reverse Sequence Errors the number of times when the current sequence number is less than the previous sequence number. Total Sequence Errors the sum of the small, big, and reverse sequence errors.
23-16
LACP Test Suite

LAG to LAG Throughput Test

This section covers the following topics: Overview of the LAG to LAG Throughput Test on page 23-17. Test Cycle on page 23-17. Test Setup: Run Parameters on page 23-18. Pass/Fail Criteria on page 23-18. Test Results on page 23-20.
Overview of the LAG to LAG Throughput Test
This test determines the maximum rate at which the DUT receives, processes, and forwards the frames without any frame loss. This test uses a one-to-one logical mapping: an Aggregated Link (LAG group) maps to another Aggregated Link (LAG group). Physically, a many-to-many traffic mapping routine is required. The aggregated link emulates a switch trunk port or multiple server NIC cards. Bidirectional traffic to/from the aggregated link to/from another aggregated link is generated and analyzed. A bundle of Aggregated links transmits traffic at a predefined rate; as the traffic reaches the DUT, it is processed by the DUT's load balancing routine for the LAG Group (LACP channel). The traffic is then fanned out onto each of the groups physical ports and the Ixia ports receive the traffic.
Test Cycle
The test starts by connecting to the chassis, configuring the ports that you set, and installing the LACP protocol per each aggregated port at the beginning of the test. Then the LAG is started on all ports. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports. The binary or the linear search algorithm is used to find out and calculate the DUT throughput. Additionally, the latency can be calculated for your test. If you specified more than one trial, the test restarts. Each time the test repeats, it calculates the DUT throughput. Each trial runs with all the frame sizes that you set for your test. After all the trials complete, the test ends. It is recommended to perform the throughput measurements with different frame sizes. When testing with different frame sizes, the DUT configuration should remain the same. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost frames. After gathering statistics, it prints the results.
23-17
23
LACP Test Suite

Pass/Fail Criteria

Table 23-7. Parameter Pass Criteria LACP LAG to LAG Throughput Test Pass/Fail Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed.
23-18
LACP Test Suite

LACP LAG to LAG Throughput Test Pass/Fail Criteria (Continued) Description Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Latency
Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/LAG: The test averages the latency over the LAG, then applies the criteria to determine whether a trial passed or failed. Maximum LAG: The test selects the longest latency experienced on each LAG, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified.
23-19
23
LACP Test Suite

Test Results
Table 23-8 describes the LACP LAG to LAG Throughput test results. These are available per flow or per port.
Table 23-8. Result TxCount RxCount Tx Tput (f/s) Tx Tput (%) Frame Loss Frame Loss (%) LACP LAG to LAG Test Results Description Total number of transmitted frames Total number of received frames Throughput, expressed in terms of frames per second (f/s) Throughput, expressed as a percentage of the theoretical maximum rate frame The number of lost frames when the network is in the process of reaching the throughput The number of lost frames, expressed as a percentage, when the network is in the process of reaching the throughput
If you enable the Sequence Checking box, the following additional test results are available: Small Sequence Errors it represents the number of times when the current sequence number minus the previous sequence is less than or equal to 2. Big Sequence Errors it represents the number of times when the current sequence number minus the previous sequence is greater than or equal to 2. Reverse Sequence Errors it represents the number of times when the current sequence number is less than the previous sequence number. Total Sequence Errors it represents the sum of the small, big, and reverse sequence errors.
23-20
LACP Test Suite

LAG to LAG Link Drop Test

This section covers the following topics: Overview of the LAG to LAG Link Drop Test on page 23-21. Test Cycle on page 23-21. Test Setup: Run Parameters on page 23-22. Pass/Fail Criteria on page 23-23. Test Results on page 23-24.
Overview of the LAG to LAG Link Drop Test
This test determines the number of dropped frames when a port becomes unavailable. This test uses a one-to-one logical mapping: an Aggregated Link (LAG group) maps to another Aggregated Link (LAG group). Physically, a many-to-many traffic mapping routine is required. The aggregated link emulates a switch trunk port or multiple server NIC cards. Bidirectional traffic is generated and analyzed from the aggregated link to another aggregated link. A bundle of Aggregated links transmits traffic at a predefined rate; as the traffic reaches the DUT it is processed by the DUT's load balancing routine for the LAG Group (LACP channel). The traffic is then fanned out onto each of the groups physical ports and the Ixia ports receive the traffic. Two measurements are calculated on a per stream basis: latency and the number of dropped frames. Then, one port on the receiving LAG group is dropped (link down). You can choose when to drop the link: between iterations or during iteration. Immediately after this, the traffic is transmitted and the DUT is supposed to redirect it to the remaining ports; the latency and the number of dropped frames per stream are calculated again. Also, the convergence time can be calculated if you enable the Convergence Calculation check box. This process iterates until the dropped ports reach the value that you set for the No. of Port Drops parameter in your test. IMPORTANT: The number of ports in the receiving LAG must be the same for all defined pairs.
Test Cycle
The test starts by connecting to the chassis, configuring the ports that you set, and installing the LACP protocol per each aggregated port at the beginning of the test. Then the LAG is started on all ports. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receiving ports. The number of dropped frames displays. Additionally, the latency can be calculated.
23-21
23
LACP Test Suite

For the next iteration, one port from the receiving LAG is dropped (link down). The process of transmitting traffic and calculating the statistics is repeated for this configuration. The latency and the number of dropped frames are calculated. Additionally, the convergence time can be calculated at this point. This process iterates until the dropped ports reach the value that you set for the No. of Port Drops parameter in your test. If you specified more than one trial, the test restarts. Each trial runs with all the frame sizes that you set for your test. The test continues until all the trials complete. It then gathers statistics on the number of transmitted and lost frames. After gathering statistics, it prints the results.
Table 23-9 lists the run parameters that are unique for this test.
Table 23-9. Parameter No. of Port Drops Convergence Calculation Link Drop Mode LAG to LAG Drop Link Test - Run Parameters Description You can set the number of ports that you want to be dropped for your test from the receiving LAG. If you check this box, the test calculates the time that the DUT needs to converge away from the withdrawn route to a new route. This allows you to choose when to drop the link on one of the ports in order to better observe the traffic distribution. You can select one of the following options: During Iteration Between Iterations
23-22
LACP Test Suite

Pass/Fail Criteria

Table 23-10. LACP LAG to LAG Drop Link Test Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The number of dropped frames compared with the number of transmitted frames. expressed as a percentage. You can select either of two methods to calculate the percentage of these frames lost: Average/LAG: The test averages the frame loss over the LAG, then applies the criteria to determine whether a trial passed or failed. Maximum LAG: The test selects the largest amount of frame loss experienced on the LAG, then applies the criteria to determine whether a trial passed or failed. Pass: The drop rate is lower than or equal to the value you entered. Fail: The drop rate exceeded the value you specified.
%Drop Rate
23-23
23
LACP Test Suite

Table 23-10. LACP LAG to LAG Drop Link Test Pass/Fail Criteria (Continued) Parameter Latency Description Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/LAG: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum/LAG: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was less than or equal to the time you specified. Fail: The latency exceeded the time you specified. Convergence The numerical threshold value for convergence time. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the convergence time: Average / LAG The test averages the convergence time over all ports, then it applies the criteria to determine whether a trial passed or failed. Maximum / LAG The test selects the longest convergence time experienced on each port, then it applies the criteria to determine whether a trial passed or failed. Pass: The convergence time was less than or equal to the time you specified. Fail: The convergence time was greater than the time you specified.
Test Results
Table 23-11 describes the LACP LAG to LAG Drop Link test results. These are available per flow or per port.
Table 23-11. LACP LAG to LAG Drop Link Test Results Result TxCount RxCount Frame Loss Frame Loss (%) Description Total number of transmitted frames Total number of received frames The number of lost frames when the network is in the process of reaching the throughput The number of lost frames, expressed as a percentage, when the network is in the process of reaching the throughput
23-24
LACP Test Suite

If you choose to calculate the convergence time for your test, the Convergence Time test result is available. If you enable the Sequence Checking box, the following additional test results are available: Small Sequence Errors it represents the number of times when the current sequence number minus the previous sequence is less than or equal to 2. Big Sequence Errors it represents the number of times when the current sequence number minus the previous sequence is greater than or equal to 2. Reverse Sequence Errors it represents the number of times when the current sequence number is less than the previous sequence number. Total Sequence Errors it represents the sum of the small, big, and reverse sequence errors.
23-25
23
LACP Test Suite

23-26
24
Chapter 24:
MEF14 Test Suite
This chapter covers the following topics: Overview of the MEF14 Test Suite on page 24-1. Setting Up the Tests on page 24-8. Frame Delay, Frame Delay Variation, Frame Loss Ratio Test on page 24-11. Bandwidth Profile Rate Enforcement Test on page 24-17. Bandwidth Profile per Ingress UNI Test on page 24-20. CIR and EIR Combined Test on page 24-23. Bandwidth Profile per CoS Test on page 24-27. Multiple Bandwidth Profiles at the UNI Test on page 24-31.
Overview of the MEF14 Test Suite

This section covers the following topics: General Information on page 24-1. Class of Service Definitions on page 24-4. EVC Related Service Performance Attributes on page 24-4. Bandwidth Profiles on page 24-5.
General Information
Metro Ethernet Forum 14 (MEF14) defines the requirements and corresponding test procedures for Service Performance and Bandwidth Profile Service Attributes that may be specified as part of a Service Level Specifications (SLS) for an Ethernet Service. The MEF14 test suite for IxAutomate has been designed to follow the Iometrix Test Plan for Traffic Management Phase 1 document. The Iometrix document uses the 10 tests defined by MEF14 and then defines many subtests (approximately 170) based on speed and frame size iterations plus other parameters
24-1
24
MEF14 Test Suite

changes. Also, the specific rates, frame sizes, percentages, and so on, spelled out by Iometrix are all included in the IxAutomate tests. The tests are currently implemented to test if the DUTs metro Ethernet services meet Service Level Specification (SLS). IxAutomate includes the following tests in the MEF14 test suite: Frame Delay, Frame Delay Variation, Frame Loss Ratio test This test is designed to meet the requirements of Section 8 of the MEF14 specification; Abstract Test Cases for EVC Related Performance Service Attributes: Test Cases 1, 2, 3. It verifies that: For all Service Frames declared Green and associated with a particular Class of Service Identifier on a Point-to-Point EVC that arrive at UNI during the specified duration, Frame Delay Performance is less than or equal to the Frame Delay Performance Objective. For all Service Frames declared Green and associated with a particular Class of Service Identifier on a Point-to-Point EVC that arrive at UNI during the specified duration, Frame Delay Variation Performance is less than or equal to the Frame Delay Variation Performance Objective. For all Service Frames declared Green and associated with a particular Class of Service Identifier on a Point-to-Point EVC that arrive at UNI during the specified duration, Frame Loss Ratio Performance is less than or equal to the Frame Loss Ratio Performance Objective. The traffic is unidirectional or bidirectional and a one-to-one traffic mapping is required. Bandwidth Profile Rate Enforcement test This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Tests 4, 5, and 6. Test Case 4 verifies that when a Bandwidth Profile is associated with a UNI, with a CIR>0 and an EIR=0, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Green (Wg) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wg. Test Case 5 verifies that when a Bandwidth Profile is associated with a UNI, with a CIR=0 and an EIR>0, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Yellow (Wy) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wy. Test Case 6 verifies that when a Bandwidth Profile is associated with a UNI, with a CIR>0 and an EIR>0, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Green (Wg) plus the amount of traffic accepted as Yellow (Wy) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wg+Wy. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN.
24-2
MEF14 Test Suite

Bandwidth Profile Per Ingress UNI test This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 7. It verifies that when a Per Ingress UNI Bandwidth Profile is associated with a UNI, the Bandwidth Profile is applied to all ingress Service Frames at that UNI. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. CIR and EIR Combined test This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 8. It verifies that when a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. Bandwidth Profile Per CoS test This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 9. It verifies that when a UNI is associated with a per Class of Service Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI with that specific Class of Service Identifier. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. Multiple Bandwidth Profiles at a UNI test This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 10. It verifies that multiple models of Bandwidth Profile application can exist simultaneously at the UNI. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN.
Figure 24-1 provides the model and framework for Ethernet Services. The technical definition of a service is in terms of what is seen by each Customer Edge (CE). This includes the User Network Interface (UNI), which is the physical demarcation point between the responsibility of the Service Provider and the responsibility of the Subscriber. The CE and MEN exchange Service Frames across the UNI. A Service Frame is an Ethernet frame transmitted across the UNI toward the Service Provider or an Ethernet frame transmitted across the UNI toward the Subscriber. The MEN could consist of a single switch or an agglomeration of networks based on many different technologies. Connectivity between UNIs is specified by the Ethernet Virtual Connection (EVC). There are a number of service attributes that an EVC can have. They are described in EVC Related Service Performance Attributes on page 24-4.
24-3
24
MEF14 Test Suite

U s e r N e tw o rk In te rfa c e (U N I)
U s e r N e tw o rk In te rfa c e (U N I)
CE
C u s to m e r E d g e (C E )
M e tro E th e rn e t N e tw o rk
CE
C u s to m e r E d g e (C E )
Figure 24-1. MEF14 Ethernet Services Model
Class of Service Definitions
Class of Service represents a set of Service Frames that have a commitment from the Service provider to receive a particular level of performance. Class of Service Identifier represents the information derivable from a) the EVC to which the service Frame is mapped or b) the combination of the EVC to which the Service Frame is mapped and a set of one or more CE-VLAN Class of Service values.
EVC Related Service Performance Attributes
A fundamental aspect of Ethernet Services is the Ethernet Virtual Connection (EVC). An EVC is an association of two or more UNIs. The EVC Related Performance Service Attributes specify the Service Frame delivery performance. Three performance attributes are described in the following: 1. Frame Delay Performance for a Service Frame, it is defined as the time elapsed from reception at the ingress UNI of the first bit of the ingress Service Frame until the transmission of the last bit of the Service Frame at the egress UNI. Table 24-1 describes the parameters for the Frame Delay Performance.
Table 24-1. Parameter T P d Frame Delay Performance Parameters Description The time interval The percentage of the Frame Delay Performance Frame Delay Performance objective
2. Frame Delay Variation Performance - it represents a measure of the variation in the frame delay between a pair of Service Frames. It is applicable to all successfully delivered Service Frames with Bandwidth Profile compliance determined to be Green for a particular Class of Service Identifier. Table 24-2 describes the parameters for the Frame Delay Variation Performance.
24-4
MEF14 Test Suite

Table 24-2. Parameter T P t d
Frame Delay Variation Performance Parameters Description The time interval Frame Delay Variation Performance percentile The separation between frame pairs for which Frame Delay Variation Performance is defined Frame Delay Variation Performance objective
3. Frame Loss Ratio Performance the definition for a particular class of service instance is based on the number of Service Frames that arrive at an ingress UNI and should be delivered to the egress UNI according to the Service Frame delivery service attributes and whose level of Bandwidth Profile compliance is determined to be Green. Table 24-3 describes the parameters for the Frame Loss Ratio Performance.
Table 24-3. Parameter T L Frame Loss Ratio Performance Parameters Description The time interval Frame Loss Ratio Performance objective
Bandwidth Profiles
A Bandwidth Profile is a characterization of ingress Service Frames arrival times and lengths at a reference point and a specification of the disposition of each Service Frame based on its level of compliance with the Bandwidth Profile. The reference point is associated here with the UNI. When a Bandwidth Profile is applied to a given sequence of ingress Service Frames, each Service Frame in the sequence is declared to be compliant or non-compliant with the Bandwidth Profile. The Bandwidth Profile defines the set of traffic parameters applicable to a sequence of Service Frames. Associated with the Bandwidth Profile is a rate enforcement algorithm to determine Service Frame compliance with the specified parameters. Rate enforcement also includes the disposition of non-compliant Service Frames by either dropping or marking.
Standard Bandwidth Profile Parameters

Table 24-4 lists the standard Bandwidth Profile parameters.
24-5
24
MEF14 Test Suite

Standard Bandwidth Profile Parameters Description It defines the average rate, in bits per second (b/s), of ingress Service Frames up to which the network delivers Service Frames and meets the performance objectives defined by the CoS Service Attribute. CIR must be equal to or greater than 0. You can set any value you want or you can choose a value from the drop-down list (if CIR is expressed as percents). Important: If CIR and EIR are expressed as percents, then the value set for CIR plus the value set for EIR must be less than or equal to 100%. Otherwise, an error message displays.
Committed Information Rate (CIR)
Committed Burst Size (CBS)
It limits the maximum number of bytes available for a burst of ingress Service Frames sent at the UNI speed to remain CIR-conformant. When CIR>0, CBS must be equal to or greater than the maximum Service Frame size. The default value is 1522 bytes. It represents the minimum value that IxAutomate allows you to set for this parameter.
Excess Information Rate (EIR)
It defines the average rate, in bits per second (b/s), of ingress Service Frames up to which the network may deliver Service Frames without any performance objectives. EIR must be equal to or greater than 0. Important: If EIR and CIR are expressed as a percentage, the value set for CIR plus the value set for EIR must be less than or equal to 100%. Otherwise, an error message displays.
Excess Burst Size (EBS)
It limits the maximum number of bytes available for a burst of ingress Service Frames sent at the UNI speed to remain EIR-conformant. When EIR>0, EBS must be equal to or greater than the maximum Service Frame size. The default value is 1522 bytes. It represents the minimum value that IxAutomate allows you to set for this parameter.
24-6
MEF14 Test Suite

Standard Bandwidth Profile Parameters (Continued) Description It allows you to choose between two modes of operation of the rate enforcement algorithm. It takes only one of the two possible values, namely 0 or 1. It has only one of the two possible values, that is, color-blind and color-aware. The CM parameter indicates whether the color-aware or color-blind property is used by the Bandwidth Profile. Color-aware A Bandwidth Profile property where a pre-determined level of Bandwidth Profile compliance for each Service Frame is taken into account when determining the level of compliance for each Service Frame. Color-blind A Bandwidth Profile property where a pre-determined level of Bandwidth Profile compliance for each Service Frame, if present, is ignored when determining the level of compliance for each Service Frame.
Coupling Flag (CF)
Color Mode (CM)
The default values for the standard parameters are defined in the Iometrix specification. For the Multiple Bandwidth Profiles at the UNI test and Bandwidth Profile Per CoS test the CoS default values are also defined in the Iometrix specification (Figure 24-2).
Figure 24-2. Bandwidth Profile Parameters and CoS
Enforcement of Bandwidth Profile Parameters

Each incoming Service Frame is classified to determine which, if any, Bandwidth Profile is applicable to the Service Frame. The operation of the Bandwidth Profile algorithm is governed by six parameters: CIR, CBS, EIR, EBS, CF, CM.
24-7
24
MEF14 Test Suite

The algorithm declares Service Frames to be compliant or non-compliant relative to the Bandwidth Profile. The level of compliance is expressed as one of three colors, Green, Yellow, or Red (see Table 24-5).
Table 24-5. Service Frame Disposition Service Frame Disposition Discard Deliver according to the Service Attributes of the service instance, but SLS performance objectives do not apply. Deliver according to the Service Attributes of the service instance and SLS performance objectives apply.
Level of Compliance Red Yellow
Green
The Bandwidth Profile algorithm is considered to be: In the color-aware mode, when each incoming Service Frame already has a level of compliance (that is, a color) associated with it and that color is taken into account in determining the level of compliance to the Bandwidth Profile parameters. The color-aware mode is optional at the UNI. In the color-blind mode, when the color, if any, already associated with each incoming Service Frame is ignored in determining the level of compliance. The color-blind mode support is required at the UNI.

Most of the MEF14 tests parameters are common to many IxAutomate tests and work the same way for all of them. Each test description includes a description of the parameters that are unique for that test. For the common Run Parameters, see Run Parameters on page 24-11. The other parameters are: Protocols: The MEF14 tests use MAC addressing. For the MAC Protocol parameters, see Configuring MAC Addresses on page 3-19. For information about the parameters that are different from the standard settings for these tests, see Frame Data Settings on page 24-9. Frame Sizes: The MEF tests require that you define the frame size of the traffic used by the test to test the DUT. For information about frame sizes, see Choosing Frame Sizes on page 3-45. For information about the parameters that are different from the standard settings for these tests, see MEF Frame Size on page 24-9. Traffic Mapping: see Setting Up the Traffic Map on page 3-11. For information about the parameters that are unique for these three tests, see Traffic Mapping Settings on page 24-9. Run Parameters on page 24-11.
24-8
MEF14 Test Suite

MEF Frame Size
In MEF mode, IxAutomate displays a list of frame sizes based on the list recommended by Iometrix. It contains three different frame sizes: 80bytes, 600 bytes, and 1500 bytes for each specified CIR. You can enable or disable each frame size by clicking the check boxes.
Frame Size list: Check boxes to enable or disable frame sizes.
Figure 24-3. MEF Frame Size
Frame Data Settings
For the MAC protocol, beside selecting the type of Ethernet frame and assigning names to ports, you can select the type of MAC frame. It can be: Unicast the traffic is sent by an ingress UNI for each egress UNI. It is the default setting. Multicast the traffic is sent by the ingress UNI to more than one egress UNI. Broadcast the traffic is sent by the ingress UNI to all egress UNIs.
Traffic Mapping Settings
You can use the Traffic Map area of the Traffic Setup window to set up a traffic map for your test. The available controls depend on whether you are creating an E-Line or an ELAN MEF map. If you choose to configure: An Automatic map, click the Exclude Ports button to remove certain ports from the map. The remaining UNIs are automatically added in the EVCs as follows: For an E-Line MEF map: For the tests that require one EVC, such as at least one UNI in one EVC, one EVC is added by default for each two UNIs; For the tests that require at least two EVCs, such as one UNI in two EVCs, two EVCs are added by default for each two UNIs. For an ELAN MEF map: For the tests that require one EVC, one EVC is added by default and it is assigned to all ingress UNIs; For the tests that require at least two EVCs, two EVCs are added by default and they are assigned to all ingress UNIs. A Manual map, click the Configure button to display the Configure EVC Mappings window (see Figure 24-4 on page 24-10). To add an EVC, you can specify the UNIs assigned to it and the CE-VLAN ID. One UNI can be assigned to one or more EVCs.
24-9
24
MEF14 Test Suite

For an ELAN MEF map, you must select at least two UNIs from the left pane (to select multiple UNIs, hold down the CTRL key) and then click Add EVC. For an E-Line MEF map, you must select two UNIs from the left pane (to select multiple UNIs, hold down the CTRL key) then click Add EVC. To remove a defined EVC, select it from the right pane, and then click Remove EVC. To add ports for an already defined EVC, use the >> button. To remove ports from an already defined EVC, use the << button.
Figure 24-4. Configure EVC Mappings Window
For an E-Line MEF traffic map, the Direction field is available to specify the direction of traffic flow for the ports: Select Unidirectional if the ports transmit only or receive only; Select Bidirectional if the ports both transmit and receive.
24-10
MEF14 Test Suite

Frame Delay, Frame Delay Variation, Frame Loss Ratio Test
Run Parameters
Table 24-6 lists the common run parameters for the MEF 14 tests.
Table 24-6. Parameter Duration MEF 14 Tests - Run Parameters Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. Load is applied to the DUT by transmitting at a rate in terms of: kilobits per second (kb/s) percentage of the maximum frame rate (%) Set the starting rate at which the frames are transmitted. Use caution when specifying low rates; the test can become less accurate if, for example, the frame rate nears 1 frame per second (f/s).
No. of Trials
Load Rate

This section covers the following topics: Overview of the Frame Delay, Frame Delay Variation, Frame Loss Ratio Test on page 24-11. Test Cycle on page 24-13. Test Setup: Run Parameters on page 24-13. Pass Criteria on page 24-14. Test Results on page 24-16.
Overview of the Frame Delay, Frame Delay Variation, Frame Loss Ratio Test
This test is designed to meet the requirements of Section 8 of the MEF14 specification; Abstract Test Cases for EVC Related Performance Service Attributes: Test Cases 1, 2, 3. This test verifies that: For all Service Frames declared Green and associated with a particular Class of Service Identifier on a Point-to-Point EVC that arrive at the UNI during the specified duration, Frame Delay Performance is less than or equal to the Frame Delay Performance Objective. For all Service Frames declared Green and associated with a particular Class of Service Identifier on a Point-to-Point EVC that arrive at the UNI during the specified duration, Frame Delay Variation Performance is less than or equal to the Frame Delay Variation Performance Objective.
24-11
24
MEF14 Test Suite

For all Service Frames declared Green and associated with a particular Class of Service Identifier on a Point-to-Point EVC that arrive at the UNI during the specified duration, Frame Loss Ratio Performance is less than or equal to the Frame Loss Ratio Performance Objective. For more information about what Green and Yellow traffic means, see Enforcement of Bandwidth Profile Parameters on page 24-7. The traffic is unidirectional or bidirectional and a one-to-one traffic mapping is required. It is recommended to run first the Bandwidth Profile per Ingress UNI test in order to check which Bandwidth Profiles pass. Then the Frame Delay, Frame Delay Variation, Frame Loss Ratio test may be run only with the passed Bandwidth Profiles. The test configuration requires: At least one EVC associating at least two UNIs; At least one Bandwidth Profile with CIR>0 associated with at least one of the UNIs.
An example test configuration is shown in the following table:

Ingress UNI A CE-VLAN ID EVC Ingress UNI B CE-VLAN ID EVC UNI Bandwidth Profile Parameters 10 EVC1 UNIA CIRA, CBSA, EIRA, EBSA 10 EVC1
NOTE: 0<CIRA<=UNI Speed; CBSA>= maximum Service Frame size
24-12
MEF14 Test Suite

MEF14 Frame Delay, Frame Delay Variation, Frame Loss Ratio

Ixia TX Ports UNIs CE-VLAN10
E Line Service
Metro Ethernet Network
UNIs CE-VLAN10
Ixia RX Ports
DUT
EVC1 with Bandwitdh Profile of CIRA, EIRA, CBSA, EBSA Maximum Line Rate Speed discard Wy<=EIR Wg <= CIR Time EIR CIR
Note: 0< CIRA< UNI Speed; CBSA>= Maximum Service Frame Size Pass/Fail Criteria: 1) Frame Delay does not exceed the specified time value 2) Frame Delay Variation does not exceed the specified time value 3) Frame Loss Ratio does not exceed the specified time value
Figure 24-5. Frame Delay, Frame Delay Variation, Frame Loss Ratio Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test and configuring the ports that you set. Also the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded through the metro Ethernet network, then by the DUT to the receive ports. In addition to checking all Service Frames declared Green, the frame delay, frame delay variation, and frame loss ratio can be calculated for the test. If you specified more than one trial, the test restarts. Each time the test repeats, it verifies all the Service Frames. Each trial runs with all the frame sizes that you set for your test. After all the trials for that frame size complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and received frames, lost frames, and, if enabled, frame delay, frame delay variation, and frame loss ratio. After gathering statistics, it prints the results.
24-13
24
MEF14 Test Suite

Frame Delay, Frame Delay Variation, Frame Loss Ratio - Run Parameters Description If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available if the IxOS version used is at least 5.10.
Calibrate Latency
CIR/EIR Unit Frame Delay
To specify the units for CIR/EIR, select percents (%) or kilobits per second (Kb/s) from the drop-down list. If you check this box, the time required to transmit a Service Frame from source to destination across the metro Ethernet network is calculated.
Frame Delay Variation If you check this box, the difference in delay of two Service Frames is calculated. Frame Loss Ratio If you check this box, the number of lost frames in the metro Ethernet network is calculated. It is expressed as a percentage.
For more information about the common run parameters, see Run Parameters on page 24-11. For more information about Bandwidth Profiles parameters, see Bandwidth Profiles on page 24-5. For information about the common settings for the MEF14 tests, see Setting Up the Tests on page 24-8. For information about other tests in this family, see MEF14 Test Suite on page 24-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass Criteria
24-14
MEF14 Test Suite

Table 24-8. Parameter Enable
Frame Delay, Frame Delay Variation, Frame Loss Ratio - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The amount of time required to transmit a Service Frame from source to destination across the metro Ethernet network. To specify the time unit, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the drop-down list. You can select either of these two methods to calculate the frame delay: Average/Port: The test averages the frame delay over all groups, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest frame delay experienced on each group, then applies the criteria to determine whether a trial passed or failed. Pass: The frame delay was less than or equal to the time you specified. Fail: The frame delay exceeded the time you specified.
Frame Delay
24-15
24
MEF14 Test Suite

Frame Delay, Frame Delay Variation, Frame Loss Ratio - Pass Criteria (Continued) Description
Frame Delay Variation The difference in delay of two Service Frames, expressed as a percentage. You can select either of these two methods to calculate the frame delay variation: Average/Port: The test averages the delay of two Service Frames over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest delay of two Service Frames on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The frame delay variation was less than or equal to the value you specified. Fail: The frame delay variation exceeded the value you specified. Frame Loss Ratio Percentage of frames transmitted that were lost across the metro Ethernet network. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Test Results
Table 24-9 describes the MEF14 Frame Delay, Frame Delay Variation, Frame Loss Ratio test results.
Table 24-9. Result Frames Sent Frames Received Frame Loss Frame Delay, Frame Delay Variation, Frame Loss Ratio Test Results Description Total number of transmitted frames Total number of received frames The number of lost frames when the network is in the process of verifying all the Service Frames.
24-16
MEF14 Test Suite

Bandwidth Profile Rate Enforcement Test
If you enable the frame delay check box for your test, the following test results are available: Min Frame Delay (ns) Max Frame Delay (ns) Avg Frame Delay (ns)
If you enable the frame delay variation check box for your test, the following test results are available: Frame Delay Variation (%) Standard Deviation (ns)
If you enable the frame loss ratio check box for your test, the following test result is available: Frame Loss Ratio (%)

This section covers the following topics: Overview of the Bandwidth Profile Rate Enforcement Test on page 24-17. Test Cycle on page 24-19. Test Setup: Run Parameters on page 24-19. Pass Criteria on page 24-19. Test Results on page 24-20.
Overview of the Bandwidth Profile Rate Enforcement Test
This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Tests 4, 5, and 6. Test Case 4 verifies that when a Bandwidth Profile is associated with a UNI, with a CIR>0 and an EIR=0, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Green (Wg) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wg. Test Case 5 verifies that when a Bandwidth Profile is associated with a UNI, with a CIR=0 and an EIR>0, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Yellow (Wy) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wy. Test Case 6 verifies that when a Bandwidth Profile is associated with a UNI, with a CIR>0 and an EIR>0, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Green (Wg) plus the amount of traffic accepted as Yellow (Wy) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wg+Wy.
24-17
24
MEF14 Test Suite

For more information about what Green and Yellow traffic means, see Enforcement of Bandwidth Profile Parameters on page 24-7. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. The test configuration requires: At least an EVC associating at least two UNIs must be configured; At least one Bandwidth Profile is applied at the UNI.
An example test configuration is presented in the following table:

Ingress UNI A CE-VLAN ID EVC Ingress UNI B CE-VLAN ID EVC UNI Bandwidth Profile Parameters 10 EVC1 UNIA CIRA, CBSA, EIRA, EBSA 10 EVC1
MEF14 Bandwidth Profile Rate Enforcement

Ixia TX Ports UNIs CE-VLAN10
E Line Service
Metro Ethernet Network
UNIs CE-VLAN10
Ixia RX Ports
DUT
EVC1 with Bandwitdh Profile of CIRA, EIRA, CBSA, EBSA Maximum Line Rate Speed discard Wy<=EIR Wg <= CIR Time EIR CIR Note: 0< CIRA< UNI Speed; CBSA>= Maximum Service Frame Size Pass/Fail Criteria: RX traffic <=Wg+Wy
24-18
MEF14 Test Suite

Figure 24-6. Bandwidth Profile Rate Enforcement Test Diagram
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded through the metro Ethernet network and then by the DUT to the receive ports. If you specified more than one trial, the test restarts. Each time the test repeats, it verifies that when a Bandwidth Profile is associated with a UNI, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Green (Wg) plus the amount of traffic accepted as Yellow (Wy) at the ingress UNI during the specified time interval, provided that the ingress traffic is greater than Wg+Wy. Each trial runs with all the frame sizes that you set for your test. After all the trials for that frame size complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and received frames, lost frames and frame loss ratio value. After gathering statistics, it prints the results.
Pass Criteria
24-19
24
MEF14 Test Suite

Bandwidth Profile per Ingress UNI Test
Table 24-10. Bandwidth Profile Rate Enforcement - Pass Criteria Parameter Enable Pass/Fail Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass criteria are applied as follows: Pass: The amount of traffic delivered at the egress UNI does not exceed (WG+WY). Fail: The amount of traffic delivered at the egress UNI exceeds (WG+WY).
Test Results
Table 24-9 describes the MEF14 Bandwidth Profile Per Ingress UNI test results.
Table 24-11. Bandwidth Profile Rate Enforcement - Test Results Result Frames Sent Frames Received Frame Loss Description Total number of transmitted frames Total number of received frames The number of lost frames when the network is in the process of verifying that, if a Bandwidth Profile is associated with a UNI, the amount of traffic delivered at the egress UNI does not exceed the amount of traffic accepted as Green (Wg) plus the amount of traffic accepted as Yellow (Wy) at the ingress UNI during the specified time interval. The number of lost frames in the metro ethernet network. It is expressed as a percentage. The status for each Ingress UNI
Frame Loss Ratio Pass/Fail Status

This section covers the following topics: Overview of the Bandwidth Profile per Ingress UNI Test on page 24-21. Test Cycle on page 24-22. Test Setup: Run Parameters on page 24-22. Pass Criteria on page 24-23. Test Results on page 24-23.
24-20
MEF14 Test Suite

Overview of the Bandwidth Profile per Ingress UNI Test
This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 7. This test verifies that when a Per Ingress UNI Bandwidth Profile is associated with a UNI, the Bandwidth Profile is applied to all ingress Service Frames at that UNI. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. The test configuration requires: that at least two EVCs, associating at least two UNIs, are configured such that each associated UNI is in at least two EVCs and at least one CE-VLAN ID is mapped per EVC; that a per Ingress UNI Bandwidth Profile is associated with at least one of the UNIs.

Ingress UNI A CE-VLAN ID EVC Ingress UNI B CE-VLAN ID EVC UNI Bandwidth Profile Parameters 10, 12 EVC1, EVC2 UNIA CIRA, CBSA, EIRA, EBSA 10, 12 EVC1, EVC2
24-21
24
MEF14 Test Suite

MEF14 Bandwidth Profile Per Ingress UNI

Ixia TX Ports UNIs CE-VLAN10 UNIs Ixia RX Ports
E Line Service Metro Ethernet Network

EVC1 EVC2 CE-VLAN12
Speed
DUT
EVC1, EVC2 with Bandwidth Profile Parameters: CIRA, EIRA, CBSA, EBSA Note: 0< CIRA< UNI Speed; CBSA>= Maximum Service Frame Size Pass/Fail Criteria: RX traffic <=Wg+Wy
Maximum Line Rate discard Wy<=EIR Wg <= CIR Time EIR CIR
Figure 24-7. Bandwidth Profile Per Ingress UNI - Test Diagram
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded through the metro Ethernet network and then by the DUT to the receive ports. If you specified more than one trial, the test restarts. Each time the test repeats, it verifies that, if a Per Ingress UNI Bandwidth Profile is associated with a UNI, the Bandwidth Profile is applied to all ingress Service Frames at that UNI. Each trial runs with all the frame sizes that you set for your test. After all the trials for that frame size complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and received frames, lost frames, and frame loss ratio value. After gathering statistics, it prints the results.
For more information about the common run parameters, see Run Parameters on page 24-11. For more information about Bandwidth Profiles parameters, see Bandwidth Profiles on page 24-5.
24-22
MEF14 Test Suite

CIR and EIR Combined Test
For information about the common settings for the MEF14 tests, see Setting Up the Tests on page 24-8. For information about other tests in this family, see MEF14 Test Suite on page 24-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass Criteria

Table 24-12. Bandwidth Profile Per Ingress UNI - Pass Criteria Parameter Enable Pass/Fail Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass criteria are applied as follows: Pass: The amount of traffic delivered at the egress UNI does not exceed (WG+WY). Fail: The amount of traffic delivered at the egress UNI exceeds (WG+WY).
Test Results
Table 24-13 describes the MEF14 Bandwidth Profile Per Ingress UNI test results.
Table 24-13. Bandwidth Profile Per Ingress UNI - Test Results Result Frames Sent Frames Received Frame Loss Description Total number of transmitted frames Total number of received frames The number of lost frames when the network is in the process of verifying that, if a Per Ingress UNI Bandwidth Profile is associated with a UNI, the Bandwidth Profile is applied to all ingress Service Frames at that UNI. The number of lost frames in the metro ethernet network. It is expressed as a percentage. The status for each Ingress UNI
Frame Loss Ratio Pass/Fail Status

This section covers the following topics: Overview of the CIR and EIR Combined Test on page 24-24. Test Cycle on page 24-25. Test Setup: Run Parameters on page 24-26.
24-23
24
MEF14 Test Suite

Pass Criteria on page 24-26. Test Results on page 24-27.
Overview of the CIR and EIR Combined Test
This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 8. Test 8 verifies that when a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. The test configuration requires: that at least two EVCs associating at least two UNIs are configured such that each associated UNI is in at least two of the same EVCs and at least one CEVLAN ID is mapped per EVC; that a per EVC Bandwidth Profile is associated with at least one of the UNIs.

Ingress UNI A CE-VLAN ID EVC Ingress UNI B CE-VLAN ID EVC EVC Bandwidth Profile Parameters 10, 12 EVC1, EVC2 EVC1, EVC2 CIR1, CBS1, EIR1, EBS1 CIR2, CBS2, EIR2, EBS2 10, 12 EVC1, EVC2
NOTE:
1. CIR1=0; CBS1=0 and EIR1= 0 and EBS1=0 2. 0< CIR2< UNI Speed; CBS2>=maximum Service Frame size 3. CIR < UNI Speed
24-24
MEF14 Test Suite

Ixia TX Ports
MEF14 CIR and EIR Combined

UNIs CE-VLAN10 UNIs
Ixia RX Ports
E Line Service Metro Ethernet Network

EVC1 EVC2 CE-VLAN12
Notes: 1) CIR1 =0; CBS1 =0 and EIR1 =0 and EBS1 =0 2) 0< CIR2< UNI Speed; CBS2>= Maximum Service Frame Size 3) CIR< UNI Speed EVC EVC1 EVC2 CE-VLAN ID 10 12 Bandwidth Profile Parameters CIR1, EIR1, CBS1, EBS1 CIR2, EIR2, CBS2, EBS2 Maximum Line Rate discard Wy<=EIR Wg <= CIR EIR CIR
DUT
Time Pass/Fail Criteria: 1) For EVC1 Rx traffic =0 2) For every other configured EVC: RX traffic <=Wg+Wy
Figure 24-8. CIR and EIR Combined Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. Once the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded through the metro Ethernet network and then by the DUT to the receive ports. If you specified more than one trial, the test restarts. Each time the test repeats, it verifies that when a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. Each trial runs with all the frame sizes that you set for your test. After all the trials for that frame size complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and received frames, lost frames, and frame loss ratio value. After gathering statistics, it prints the results.
Speed
24-25
24
MEF14 Test Suite

The Bandwidth Profile Configuration section allows you to perform the following operations: Using the Add CoS button you can add for each defined EVC one or more Class(es) of Service. The bandwidth parameters are available and configurable for each of the added Class(es) of Service. The same rules as for the EVCs are applied for the Class(es) of Service. Using the Delete CoS button you can remove the selected Class(es) of Service.
Pass Criteria

Table 24-14. CIR and EIR Combined - Pass Criteria Parameter Enable Pass/Fail Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The pass criteria are applied as follows: 1. For EVC1: Pass: The amount of traffic delivered at the egress UNI is equal to 0. Filthy amount of traffic delivered at the egress UNI is greater than 0. 2. : For every other configured EVC: Pass: The amount of traffic delivered at the egress UNI does not exceed (WG+WY). Fail: The amount of traffic delivered at the egress UNI exceeds (WG+WY).
24-26
MEF14 Test Suite

Bandwidth Profile per CoS Test
Test Results
Table 24-15 describes the MEF14 CIR and EIR Combined test results.
Table 24-15. CIR and EIR Combined - Test Results Result Frames Sent Per Port Per EVC Frames Received Per Port Per EVC Frame Loss Per Ingress UNI Per EVC Description Total number of transmitted frames per port per EVC Total number of received frames per port per EVC The number of lost frames when the network is in the process of verifying that, if a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. The status for each Ingress UNI
Pass/Fail Status

This section covers the following topics: Overview of the Bandwidth Profile per CoS Test on page 24-27. Test Cycle on page 24-29. Test Setup: Run Parameters on page 24-30. Pass Criteria on page 24-30. Test Results on page 24-30.
Overview of the Bandwidth Profile per CoS Test
This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 9. Test 9 verifies that when a UNI is associated with a per Class of Service Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI with that specific Class of Service Identifier. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. For more information about what Class of Service and Class of Service Identifier means, see Class of Service Definitions on page 24-4. The test configuration requires: that at least one EVC associating at least two UNIs is configured and at least one CE-VLAN ID is mapped per EVC. that a per Class of Service Bandwidth Profile is associated with at least one of the UNIs.
24-27
24
MEF14 Test Suite

that at least two CoS Identifiers are used to identify the Class of Service applicable to the Service Frames offered at the UNI.

Ingress UNI A CE-VLAN ID EVC Ingress UNI B CE-VLAN ID EVC EVC CoS Identifier CE-VLAN ID Bandwidth Profile Parameters 10 EVC1 EVC1 1, 2 1, 7 CIR11, CBS11, EIR11, EBS11 CIR12, CBS12, EIR12, EBS12 10 EVC1
NOTE:
24-28
MEF14 Test Suite

MEF14 Bandwidth Profile Per CoS

Ixia TX Ports
UNIs CE-VLAN10 UNIs CE-VLAN10
Ixia RX Ports
E Line Service Metro Ethernet Network EVC1
DUT
CoS1 Traffic CoS7 Traffic

Notes: 1) CIR11 =0; CBS11 =0 and EIR11 =0 and EBS11 =0 2) 0< CIR12< UNI Speed; CBS12>= Maximum Service Frame Size 3) CIR< UNI Speed EVC CoS CE-VLAN Identifier CoS 1 EVC1 2 7 1 Bandwidth Profile Parameters CIR11, EIR11, CBS11, EBS11, CIR12, EIR12, CBS12, EBS12, Speed
Maximum Line Rate discard Wy<=EIR Wg <= CIR Time Pass/Fail Criteria: 1) For CoS ID=0: Rx traffic =0 2) For every other configured CoS ID: RX traffic <=Wg+Wy EIR CIR
Figure 24-9. Bandwidth Profile Per CoS Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. The INFO lines specify the total information rate of the bandwidth profiles applied to each UNI and also the configuring setup available for Bandwidth Profile per EVC per CoS. After the transmit and receive ports are configured, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded through the metro Ethernet network and then by the DUT to the receive ports. If you specified more than one trial, the test restarts. Each time the test repeats, it verifies that when a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. Each trial runs with all the frame sizes that you set for your test. After all the trials for that frame size complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and received frames, lost frames, and frame loss ratio value. After gathering statistics, it prints the results.
24-29
24
MEF14 Test Suite

Pass Criteria

Table 24-16. Bandwidth Profile Per CoS - Pass Criteria Parameter Enable Pass/Fail Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The criteria are applied as follows: 1. For CoS ID 1: Pass: The amount of traffic delivered at the egress UNI is equal to 0. Fail: The amount of traffic delivered at the egress UNI is greater than 0. 2. : For every other configured CoS ID: Pass: The amount of traffic delivered at the egress UNI does not exceed (WG+WY). Fail: The amount of traffic delivered at the egress UNI exceeds (WG+WY).
Test Results
Table 24-15 describes the MEF14 Bandwidth Profile Per CoS test results.
24-30
MEF14 Test Suite

Multiple Bandwidth Profiles at the UNI Test
Table 24-17. Bandwidth Profile Per CoS - Test Results Result Frames Sent Per Port Per EVC Frames Received Per Port Per EVC Frame Loss Per Ingress UNI Per EVC Description Total number of transmitted frames per port per EVC Total number of received frames per port per EVC The number of lost frames when the network is in the process of verifying that, if a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. The status for each Ingress UNI
Pass/Fail Status

This section covers the following topics: Overview of the Multiple Bandwidth Profiles at the UNI Test on page 24-31. Test Cycle on page 24-33. Test Setup: Run Parameters on page 24-34. Pass Criteria on page 24-34. Test Results on page 24-34.
Overview of the Multiple Bandwidth Profiles at the UNI Test
This test is designed to meet the requirements of section 9 of the MEF14 specification: Abstract Test Cases for Bandwidth Profiles Service Attributes, Test 10. Test 10 verifies that multiple models of Bandwidth Profile application can exist simultaneously at the UNI. A one-to-one traffic mapping is required for E-Line and a many-to-many traffic mapping is required for ELAN. The traffic is unidirectional or bidirectional for E-Line and only bidirectional for ELAN. The test configuration requires: that at least two EVCs associating at least two UNIs are configured such that each associated UNI is in at least two of the same EVCs and at least one CEVLAN ID is mapped per EVC. that a per Bandwidth Profile and a per Class of Service Bandwidth Profile are associated with at least one of the UNIs.
24-31
24
MEF14 Test Suite

Ingress UNI A CE-VLAN ID EVC Ingress UNI B CE-VLAN ID EVC Per EVC EVC Bandwidth Profile Parameters Per Class of Service EVC CoS Identifier CE-VLAN ID Bandwidth Profile Parameters EVC2 1, 2 1, 7 CIR21, CBS21, EIR21, EBS21 CIR22, CBS22, EIR22, EBS22 EVC1 CIR1, CBS1, EIR1, EBS1 10, 12 EVC1, EVC2 10, 12 EVC1, EVC2
NOTE:
24-32
MEF14 Test Suite

MEF14 Multiple Bandwidth Profiles at the UNI

Ixia TX Ports UNIs CE-VLAN10 UNIs Ixia RX Ports
E Line Service
Metro Ethernet Network EVC1 EVC2 CE-VLAN12 CoS1 Traffic CoS7 Traffic
Pass/Fail Criteria: 1) For CoS ID1 Rx traffic =0 2) For every other configured EVC and CoS ID: RX traffic <=Wg+Wy Maximum Line Rate Speed discard Wy<=EIR Wg <= CIR Time EIR CIR
DUT
EVC1 with Bandwitdh Profile of CIR1, EIR1, CBS1, EBS1 Note: 0< CIR1< UNI Speed; CBS1>= Maximum Service Frame Size EVC CoS CE-VLAN Bandwidth Profile Parameters Identifier CoS CIR21, EIR21, CBS21, EBS21 1 1 2 7 CIR22, EIR22, CBS22, EBS22
EVC2
Notes: 1) CIR21 =0; CBS21 =0 and EIR21 =0 and EBS21 =0 2) 0< CIR22< UNI Speed; CBS22>= Maximum Service Frame Size 3) CIR< UNI Speed
Figure 24-10.Multiple Bandwidth Profiles at the UNI Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. After the transmit and receive ports are configured and the setup configuration is done for Bandwidth Profile Per EVC, the frames are transmitted. The test allows two seconds for any additional frames to come in. After transmitting all the frames, the test collects statistics on how many of the transmitted frames were forwarded through the metro Ethernet network. If you specified more than one trial, the test restarts. Each time the test repeats, it verifies that when a UNI is associated with a per EVC Bandwidth Profile, the Bandwidth Profile is applied to all ingress Service Frames at the UNI on that EVC. Each trial runs with all the frame sizes that you set for your test. After all the trials for that frame size complete, the test either ends or, if you specified more than one frame size for one part, it restarts with the next largest frame size. The test continues until all the trials and frame sizes complete. It then gathers statistics on the number of transmitted and received frames, lost frames, and frame loss ratio value. After gathering statistics, it prints the results.
24-33
24
MEF14 Test Suite

Pass Criteria

Table 24-18. Multiple Bandwidth Profiles at the UNI - Pass Criteria Parameter Enable Pass/Fail Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The criteria are applied as follows: 1. For CoS ID 1: Pass: The amount of traffic delivered at the egress UNI is equal to 0. Fail: The amount of traffic delivered at the egress UNI is greater than 0. 2. : For every other configured EVC and CoS ID: Pass: The amount of traffic delivered at the egress UNI does not exceed (WG+WY). Fail: The amount of traffic delivered at the egress UNI exceeds (WG+WY).
Test Results
Table 24-19 describes the MEF14 Multiple Bandwidth Profiles at the UNI test results.
24-34
MEF14 Test Suite

Table 24-19. Multiple Bandwidth Profile at the UNI - Test Results Result Frames Sent Frames Received Frame Loss Bits Received Max Allowed Traffic Pass/Fail Status Description Total number of transmitted frames Total number of received frames The number of lost frames across the metro Ethernet network The number of bits received The traffic allowed, expressed in bits The status for each Ingress UNI
24-35
24
MEF14 Test Suite

24-36
25
Chapter 25:
Triple Play Test Suite
This chapter covers the following topics: Overview of the Triple Play Test Suite on page 25-1. Scalability Test on page 25-2. Setting Up the Test on page 25-3. Pass/Fail Criteria on page 25-25. Test Cycle on page 25-28. Test Results on page 25-29.
Overview of the Triple Play Test Suite

Triple Play is a general term referring to the delivery of Voice, Video, and Data services to an end-user as a unified service. From the end-user's perspective, triple play services are typically delivered as Voice over IP (VoIP), Video on Demand (VoD), and High Speed Internet (HSI) over DSL (Digital Subscriber Line) or Cable connections. IxAutomate includes the following test in the Triple Play test suite: Scalability test This test consists of equal measurement intervals, measuring, for each interval, the traffic and service characteristics. It is a Proof of Concept test (PoC) that varies the traffic and service characteristics from the starting values, during test interval 1, to the end values, during test interval N, in order to find the limits of the network. There is an N+1 interval that uses the same traffic characteristics as interval 1, in order to test if the network recovers from possible overload conditions generated during interval N.
25-1
25

Scalability Test
Scalability Test
This test consists of equal measurement intervals. The length of these intervals and the number of iterations are configurable parameters. The test varies the traffic and service characteristics, from the starting values during the test interval 1, to the set end values during the test interval N, in order to find the limits of the network. Also, an additional test interval N+1 is used, after the N test interval, having the same traffic characteristic as the interval 1, to check if the network recovers from possible overload conditions generated during the test interval N. Figure 25-1 on page 25-2 shows the network topology used for this test: The core it contains a VPLS network; The client side it contains xDSL (Digital Subscriber Line) modems, which are connected through a DSLAM (Digital Subscriber Line Access Multiplexer) device to the core; The network (server) side it contains PPP termination equipment (BRAS Broadband Residential Access Servers), MSIPTV (Microsoft IPTV) service, and Voice over IP users (NGN Next Generation Networking).
xDSL Modem
DSLAM
Switch
DHCP Server
Router xDSL Modem
Router
BRAS
Internet
MPLS Aggregation Ring
NGN (VoIP)
Router xDSL Modem
Router
DSLAM
Router
A Server
xDSL Modem
D Server
V Server
Figure 25-1. Network Topology Diagram
Figure 25-2 shows the flow traffic diagram for this test.
25-2

Setting Up the Test
Ixia Ports
xDSL Modems DSLAM/ nCPE
Triple Play Scalability
Ixia Ports
VoIP Server
Video Server
HSI Server
DUT
xDSL Modems DSLAM/ nCPE
MPLS Network
VoIP Server
Entry Router/ DSLAM
Video Server
HSI Server
Notes: 1. When choosing Layer 2-3 traffic type for the simulated servers, VoIP servers and Video servers and HSI servers can be simulated on the same Ixia port. 2. When choosing Layer 4-7 traffic type for the simulated servers, only one type of server (VoIP server or Video server or HSI server) can be simulated on an Ixia port.
Figure 25-2. Scalability Test Traffic Flow Diagram
Setting Up the Test

To set up the traffic and test parameters: Traffic Setup parameters: Allows you to set the client side, the server side, and also to configure the port mapping. For further information, see Traffic Setup Parameters on page 25-3. Test Setup parameters: The description of each parameter is available in Test Setup Parameters on page 25-23.
For information about using all the IxAutomate options available for the tests, see Creating and Running IxAutomate Tests on page 3-1.
The Traffic Setup window contains three different tabs, allowing you to set up the: Client Side Configuration on page 25-3. Server Side Configuration on page 25-17. Client/Server Port Mapping on page 25-22.
Client Side Configuration

The Client Traffic tab (Figure 25-3) allows you to set up: the devices added on the client side; for more information, see Devices on page 25-4;
25-3
25

Setting Up the Test
the services for the selected device; for more information, see Services on page 25-6; the traffic profile for the selected service; for more information, see Traffic Profiles on page 25-7.
Devices area
Services for the selected device area
Traffic profiles for the selected service area
Figure 25-3. Client Traffic Tab
Devices On the client side, an Ixia port simulates one of the following types of devices: DSLAM it has 1 Gigabit Ethernet interface to connect to the core. This port receives and sends all the traffic to and from clients. The Ixia port simulates only the traffic sent through this port by an DSLAM. nCPE in this setup, n xDSL modems are used (an Ixia port can emulate a set of n xDSL modems), connected to a real DSLAM. The modems are set in a special transparent mode so that the traffic for all services comes on the Ethernet port. The Ethernet ports of the modems are connected to a switch. The Ixia port is connected to this switch as well. If using different VLANs, the traffic is sent through different modems, simulating n users (1 for each modem). In the real world setup, three ports are used on the xDSL modem, one for each type of service (voice, video, and data). To add a device on the client side: 1. Select the Client Traffic tab from the Traffic Setup window; 2. Click the Add button from the Devices section.
25-4

Setting Up the Test
If you decide to delete one of the listed devices, select it from the list and click the Remove button. Table 25-1 lists the configuration parameters for a device.
Table 25-1. Parameter Name Configuration Parameters for a Device Description Enter a name for the device. A default name is available for the added device, but if you want to replace the default name, double-click inside the field and enter the desired name. Type Choose from the drop-down list the type of the device to be emulated on the Ixia port. The available options are DSLAM and nCPE. The default value is DSLAM. Set the number of xDSL subscribers emulated on the Ixia port. The default value is 768 xDSL subscribers. When emulating an DSLAM device on the Ixia port, set the VLAN ID used for communication between DSLAM and Entry router in MPLS core. The VLAN ID is used for multicast group joins, and the multicast streams are received tagged with this VLAN ID. When emulating an nCPE device, this parameter field is not used. The default value is 200. User VLAN Type Choose from the drop-down list the type of the VLAN for the user. The available options are: Inner when setting this option, Stacked VLAN is used, if the Service VLAN Type parameter is set in turn to the Outer option. Outer when setting this option: Stacked VLAN is used, if also the Service VLAN Type parameter is set to Inner; Single VLAN is used, if also the Service VLAN Type parameter is set to None. None when setting this option: No VLAN is used, if also the Service VLAN Type parameter is set to None; Single VLAN is used, if also the Service VLAN Type parameter is set to Outer.
xDSL Subscribers Broadcast VLAN
25-5
25

Setting Up the Test
Configuration Parameters for a Device (Continued) Description Choose from the drop-down list the type of VLAN for service VLAN. The available options are: Inner when setting this option, Stacked VLAN is used, if also the User VLAN Type parameter is set to the Outer option. Outer when setting this option: Stacked VLAN is used, if also the User VLAN Type parameter is set to Inner; Single VLAN is used, if also the User VLAN Type parameter is set to None. None when setting this option: No VLAN is used, if also the User VLAN Type parameter is set to None; Single VLAN is used, if also the User VLAN Type parameter is set to Outer.
Service VLAN Type
MAC Address
When emulating an DSLAM device on the Ixia port, enter the MAC address for the DSLAM device. This is used as source MAC address when sending multicast join messages. When emulating an nCPE device, this parameter field is not used.
IP Address/Network Mask
When emulating an DSLAM device on the Ixia port, enter the IP address and the network mask bits for the DSLAM device (the order for entering the information in this field is: IP address/network mask). This is used as source IP address when sending multicast join messages and as first relay IP if IP Resolution for services enabled on device is set to DHCP. When emulating an nCPE device, this parameter field is not used.
Traffic
Choose from the drop-down list the type of traffic you want to use for your device. The available options are: Layer 2-3 Layer 4-7 The default value is Layer 2-3.
Services When selecting a device, a list of services is available for configuration in the Services area. Three types of services are available for each selected device: HSI (Hish Speed Internet) service VoIP (Voice over IP) service Video service
25-6

Setting Up the Test
One Ixia port can simulate one or more services. Table 25-2 lists the configuration parameters for a service.
Table 25-2. Parameter Enable Service User VLAN Start Configuration Parameters for a Service Description If you enable the check box, the corresponding service is used for the selected device. The service name. This is a read-only parameter and it cannot be modified. The starting VLAN tag for the VLAN user. The default values are: 1000 for the VoIP traffic service 2000 for the Video traffic service 3000 for the HSI traffic service User VLAN Step Specify the step for incrementing the User VLAN Start value until the number of subscribers is reached. The default value is 1. Service VLAN Specify the VLAN tag for the service VLAN. The default values are: 100 for the VoIP traffic service 101 for the Video traffic service 102 for the HSI traffic service IP Resolution Choose from the available drop-down list, how to allocate IP addresses in the network. The available options are: Static the IP addresses are assigned to the clients through a static allocation process. DHCP the clients acquire the IP addresses from a DHCP server. PPP the clients acquire the IP addresses from a real access server. PPP with Server Emulation the clients acquire the IP addresses from an emulated access server on another Ixia port (the corresponding server port for that traffic profile).
Traffic Profiles When selecting a service, the corresponding traffic parameters display in the Traffic Profile area. Depending on the selected service and the emulated traffic, different traffic profiles parameters are available. The traffic choices are: Layer 2-3 the emulated device generates stateless traffic Layer 4-7 the emulated device generates stateful traffic
This section describes the parameters available in the Traffic Profile area:
25-7
25

Setting Up the Test
Layer 2/ Layer 3 Configuration on page 25-8. Layer 2-3 Traffic Profile on page 25-11. Layer 4-7 Traffic Profile for VoIP service on page 25-12. Layer 4-7 Traffic Profile for Video Service on page 25-13. Layer 4-7 Traffic Profile for HSI Service on page 25-15.
Layer 2/ Layer 3 Configuration The L2/L3 Configuration parameters are the same for both Layer 2-3 and Layer 4-7 traffic type. They depend on the IP Resolution selection: IP resolution set to Static (Table 25-3 on page 25-8)
L2/L3 Configuration - IP Resolution Static Description The first MAC address from a pool of MAC addresses that are assigned to the clients The incrementing step used for MAC Address Start for allocating MAC addresses for all the specified subscribers The first IP address from a pool of IP addresses that are assigned to the clients The incrementing step used for IP Address Start to allocate IP addresses for all specified subscribers This is an optional parameter. Specify the gateway IP address if needed. The default value is 0.0.0.0. The mask for the IP address assigned to the clients
MAC Address Start MAC Address Step
IP Address Start IP Address Step Gateway Mask
IP Resolution set to DHCP (Table 25-4)

L2/L3 Configuration - IP Resolution DHCP Description The first MAC address from a pool of MAC addresses that are assigned to the clients The incrementing step used for MAC Address Start for allocating MAC addresses for all the specified subscribers Specify the IP address for the DHCP server. This is an optional parameter. Specify the IP address for the DHCP gateway. The default value is 0.0.0.0.
DHCP Server DHCP Gateway
25-8

Setting Up the Test
L2/L3 Configuration - IP Resolution DHCP Description Combined with the Agent Remote ID parameter, this parameter gives DHCP option 82. The string can be variable for each client. To change a specific part of the stream, the following format must be used: %StartValue:Count:Repeati. The substring starts with a % sign and ends with i. The first field describes the substring width (001-width of 3; 01-width of 2). The repeat count is not mandatory (when it is not present, the default value of 1 is used). Example format for ATM 1/1 %03:16:48i/ %01:48i:8.35.
Agent Circuit ID
Agent Remote ID
Combined with the Agent Remote ID parameter, this parameter gives DHCP option 82. The default value is remoteID.
IP Resolution set to PPP (Table 25-5)

L2/L3 Configuration - IP Resolution PPP Description The first MAC address from a pool of MAC addresses that are assigned to the clients The incrementing step used for MAC Address Start for allocating MAC addresses for all the specified subscribers. This parameter is read only, and the value is set to 00:00:00:00:00:01 The IP address for the PPP server The username used for PPP authentication. The string can contain variable substrings specified as in DHCP Agent Circuit ID. If no authentication is required, leave the field empty. The password used for PPP authentication. The string can contain variable substrings specified as in DHCP Agent Circuit ID. If no authentication is required, leave the field empty. Combined with the Agent Remote ID parameter, this parameter gives the PPP Relay Tag. The string can contain variable substrings specified as in DHCP Agent Circuit ID. Combined with the Agent Circuit ID parameter, this parameter gives the PPP Relay Tag. The default value is remoteID.
Remote IP Username
Password
Agent Circuit ID
Agent Remote ID
25-9
25

Setting Up the Test
IP Resolution set to PPP with Server Emulation (Table 25-6)

L2/L3 Configuration - IP Resolution PPP with Server Emulation Description The first MAC address from a pool of MAC addresses that are assigned to the clients The incrementing step used for MAC Address Start for allocating MAC addresses for all the specified subscribers The IP address for the PPP server The username used for PPP authentication. The string can contain variable substrings specified as in DHCP Agent Circuit ID. If no authentication is required, leave the field empty. The password used for PPP authentication. The string can contain variable substrings specified as in DHCP Agent Circuit ID. If no authentication is required, leave the field empty. This parameter combined with Agent Remote ID parameter gives the PPP Relay Tag. The string can contain variable substrings specified as in DHCP Agent Circuit ID. This parameter combined with Agent Circuit ID parameter gives the PPP Relay Tag. The default value is remoteID. The IP address that the PPP server assigns to the first subscriber The incrementing step value applied to the Local IP Start in order to allocate IP addresses for all the specified subscribers.
Remote IP Username
Password
Agent Circuit ID
Agent Remote ID
Local IP Start Local IP Step
25-10

Setting Up the Test
Layer 2-3 Traffic Profile Table 25-7 lists the configuration parameters for a traffic profile when choosing Layer 2-3 traffic type.
Table 25-7. Parameter Enable Type Configuration Parameters for Layer 2-3 Traffic Profile Description If you enable the check box, the corresponding traffic profile is used for the selected service. The available types of traffic for each service are: For VoIP traffic service, only SIP traffic can be generated For Video traffic service, three different types of traffic can be generated: BTV-Unicast (Broadcast Television - Unicast) BTV-Multicast (Broadcast Television - Multicast) VoD (Video on Demand) For HSI traffic service, three different types of traffic can be generated: Premium Silver Bronze Users (%) Frame Size (bytes) Bandwidth Upstream (Bdw US) Bandwidth Downstream (Bdw DS) DSCP Upstream Set the user percentage value used for the selected type of generated traffic. The default value is 20. Set the frame size for the selected traffic profile. The default value is 128. Set the bandwidth for the upstream traffic. The parameter field value is not used for BTV-Multicast traffic. Set the bandwidth for downstream traffic. The parameter field value is not used for BTV-Multicast traffic. Set the DSCP value for upstream traffic. The parameter field value is not used for BTV-Multicast traffic. Set the DSCP value for downstream traffic. The parameter field value is not used for BTV-Multicast traffic. Set the 802.1p value for upstream traffic. The parameter field value is not used for BTV-Multicast traffic. Set the 802.1p value for downstream traffic. The parameter field value is not used for BTV-Multicast traffic.
DSCP Downstream
802.1p Upstream
802.1p Downstream
25-11
25

Setting Up the Test
Layer 4-7 Traffic Profile for VoIP service The application simulates an endpoint-to-endpoint conversation, in which both peers are emulated by the Ixia equipment. In the implemented scenario, the users perform the following actions: Initiate Call Voice Session End Call
Two types of parameters are available to be configured: Traffic profile properties, described in Table 25-8; VoIP service parameters, described in Table 25-9 on page 25-13.
Layer 4-7 Traffic Profile - VoIP Service Description If you enable the check box, the corresponding traffic profile is used for the selected service. The only type of traffic available for the VoIP service is SIP. Set the user percentage value used for the SIP traffic profile. The default value is 20. Set the DSCP value inserted into the IP packets sent from the client to the server. The default value is 46. Set the DSCP value inserted into the IP packets sent from the server to the client. The default value is 46. Set one of the VoIP servers configured in the Server Traffic tab. For more information, see Server Side Configuration on page 25-17.
Table 25-8. Parameter Enable Type Users (%)
DSCP Upstream DSCP Downstream Server
25-12

Setting Up the Test
Layer 4-7 - VoIP Service Parameters Description Choose the voice codec from the drop-down list. The available options are: G711ALaw G711Ulaw G729A G729B G726 G723_1 The Codec Details and the Bit Rate parameters have different default values for each of the listed codecs.
Codec Name
Codec Details
The details for the selected codec in the Codec Name parameter field. Multiple details options are available for each voice codec in the drop-down list. The bit rate for the selected codec in the Codec Name parameter field. Depending on the selected voice codec, one or multiple options are available for this parameter. Select the period of time, in seconds (s), that represents the conversation time (the duration of the voice session). If you enable this check box, the buffer jitter can be used. Set the number of packets to buffer in order to reduce the jitter. If you check this check box, the SIP Proxy can be used. You should enter the IP address for the SIP Proxy. If you check this check box, you should enter the User Name, the Password, and the Domain for authentication. Specify the username for SIP Proxy authentication. Specify the password for SIP Proxy authentication. Specify the domain for SIP Proxy Authentication.
Bit Rate
RTP Duration
Use Jitter Buffer Size Use SIP Proxy
Use Proxy Authentication Username Password Domain
Layer 4-7 Traffic Profile for Video Service The test simulates two scenarios: 1. Users zapping between channels. The switch between two channels involves a request to the D-Server (unicast server), and then the request to the AServer (multicast server).
25-13
25

Setting Up the Test
2. Users receiving unicast stream for a period of time from a specific video server (Video on Demand VoD). Two types of parameters are available to be configured: Traffic profile properties, described in Table 25-10; Video service parameters, described in Table 25-11 on page 25-15.
Table 25-10. Layer 4-7 Traffic Profile - Video Service Parameter Enable Type Description If you enable the check box, the corresponding traffic profile is used for the selected service. The available traffic profiles for the Video service are: BTV-Unicast BTV-Multicast VoD IMPORTANT: Due to the limitation of the coexistence under the same Ixia port of both A server (multicast) and D-Server (unicast), the BTV-Unicast and BTVMulticast traffic profiles are synchronized, meaning they must be checked/unchecked together and they must have set the same destination server. Users (%) Set the user percentage value used for the selected type of traffic. The default value is 20 for all the available traffic profiles. Set the DSCP value inserted into the IP packets sent from the client to the server. The default value is 34. Set the DSCP value inserted into the IP packets sent from the server to the client. The default value is 34. Set one of the Video servers configured in the Server Traffic tab. For more information, see Server Side Configuration on page 25-17.
DSCP Upstream DSCP Downstream Server
25-14

Setting Up the Test
Table 25-11. Layer 4-7 - Video Service Parameters Parameter Delay After DRequest (sec) Channel Viewing Sequence Description It represents the period of time, expressed in seconds (s), to wait after the unicast request was sent before sending the multicast stream. Choose from the available drop-down list the order in which the clients join the multicast groups. The available options are: Sequential the client plays the channels defined in Channel Allocation in order, one after the other, based on their IP addresses (the first IP address is the one set for Starting Group Address from Video Server Configurations; for more information, see Server Side Configuration on page 25-17). When the channel Watch Duration expires, the client sends an IGMP Leave message for the watched channel; then, the client waits for the period specified in the Channel Switch Delay parameter field, before joining the next group to play the next channel. Random the client plays the channels defined in Channel Allocation randomly. Poisson the client plays the channels in Poisson distribution order. The value for varLambda is set by default to 25 (hard-coded parameter). Normal the client plays the channels in an order that follows a normal distribution. Watch Duration (sec) Set the period of time, expressed in seconds (s), to wait before sending the IGMP leave message for the watched channel.
Layer 4-7 Traffic Profile for HSI Service To test the DUTs transfer capabilities, the test uses the HTTP protocol. On the client side, it emulates users (browsers) initiating HTTP transactions to the HTTP servers configured in the Server Traffic tab (for more information, see Server Side Configuration on page 25-17). To characterize the downstream and the upstream, the test configures two user profiles: one initiating HTTP GET requests and the other HTTP POST requests. Two types of parameters are available to be configured: Traffic profile properties, described in Table 25-12 on page 25-16; HSI service parameters, described in Table 25-13 on page 25-16.
25-15
25

Setting Up the Test
Table 25-12. Layer 4-7 Traffic Profile - HSI Service Parameter Enable Type Description If you enable the check box, the corresponding traffic profile is used for the selected service. The available traffic profiles for the HSI service are: Premium Silver Bronze The traffic profiles differ by the DSCP values assigned to the IP packets, as the DUT prioritizes the traffic based on the DSCP values. Users (%) Set the user percentage value used for the selected type of traffic. The default value is 20 for all the available traffic profiles. Set the DSCP value inserted into the IP packets that encapsulates the HTTP requests from client to server. The default value is different for each traffic profile: 18 for Premium traffic profile 10 for Silver traffic profile 0 for Bronze traffic profile DSCP Downstream Set the DSCP value inserted into the IP packets sent from the simulated HTTP server in response to the HTTP client requests. The default value is different for each traffic profile: 18 for Premium traffic profile 10 for Silver traffic profile 0 for Bronze traffic profile Server Set the destination server. The simulated HTTP server is configured in Server Traffic tab. For more information, see Server Side Configuration on page 25-17.
DSCP Upstream
Table 25-13. Layer 4-7 - HSI Service Parameters Parameter MSS (bytes) Description It represents the Maximum Segment Size. This is the maximum TCP segment size allowed. The default value is 1460. Set the size of the web page, expressed in kilobytes, returned by the server in response to the HTTP GET request. This parameter is important for the downstream tests. Set the size of the uploaded file, expressed in kilobytes, as result of the HTTP POST command. The parameter is important for the upstream tests.
GET (kbytes)
POST (kbytes)
25-16

Setting Up the Test
Server Side Configuration

The Server Traffic tab (Figure 25-4) allows you to set servers with different types of services. The servers are grouped by the type of service provided, as follows: VoIP servers Video servers HSI servers
For Layer 2-3 traffic type servers, load distribution can be achieved by configuring multiple servers for the same service type and assigning them to one or multiple Ixia ports. The sum of the load values for these servers has to be 100 for the same service type.
Figure 25-4. Server Traffic Tab
The device used between the server side and the edge router may be a router or a switch. Instances of Servers For each type of service, multiple instances of servers could be added. Below are listed the available instances of services, for each available type of service: VoIP service Layer 2-3 it emulates stateless VoIP traffic Layer 4-7 it emulates stateful VoIP traffic Video service: IPTV-A Layer 2-3 it emulates stateless multicast traffic. Only one instance can be added within a test. IPTV-D Layer 2-3 it emulates stateless unicast traffic generated by a DServer. IPTV-V Layer 2-3 it emulates stateless unicast traffic generated by a VServer (Video on Demand).
25-17
25

Setting Up the Test
IPTV-AD Layer 4-7 it emulates stateful multicast traffic. The A and D servers coexist as a single entity and must be assigned to only one Ixia port. IPTV-V Layer 4-7 it emulates stateful unicast traffic (the video on demand service). HSI service: Layer 2-3 it emulates stateless HTTP traffic Premium - Layer 4-7 it emulates a HTTP server which is targeted by the HSI premium traffic profile. Silver - Layer 4-7 it emulates a HTTP server which is targeted by the HSI silver traffic profile. Bronze - Layer 4-7 it emulates a HTTP server which is targeted by the HSI bronze traffic profile. To add one or multiple instances for each type of server (the only exception is the IPTV-A Layer 2-3 server): 1. Select the Server Traffic tab from the Traffic Setup window. 2. Set one of the three available service types. 3. Click the Add button. If you decide to delete an instance of the servers from the available list, select it and click the Remove button. Table 25-14 lists the parameters available for all types of server configuration.
Table 25-14. Server Configuration Parameters Parameter Service Traffic Type Description The service name is a read-only field. The available types of services are VoIP, Video, and HSI. The instance server traffic type used. The available options are: VoIP: Layer 2-3, Layer 4-7. Video: IPTV-A Layer 2-3; IPTV-D Layer 2-3; IPTV-V Layer 2-3; IPTV-AD Layer 4-7; IPTV-V Layer 4-7. HSI: Layer 2-3; Premium - Layer 4-7; Silver - Layer 4-7; Bronze - Layer 4-7. For more information about the available instances, see Instances of Servers on page 25-17. Server IP Address Mask The name of the server configured for the specific service The IP address of the server The network mask of the server
25-18

Setting Up the Test
Table 25-14. Server Configuration Parameters (Continued) Parameter Gateway Description The IP address of the gateway, when required. By default, no gateway is required and the IP address is 0.0.0.0. VLAN VLAN ID MAC Address Load If you enable this check box, the traffic from the configured server is tagged. The tag value used for the server traffic The MAC address of the server The percentage from the whole subscribers traffic targeted to the configured server. For the first server added, this value is set by default to 100. This parameter is used only by Layer 2-3 servers.
For the Video service, additional parameters can be configured for the following server instances: IPTV-A Layer 2-3 on page 25-19. IPTV-AD Layer 4-7 on page 25-21. IPTV-V Layer 4-7 on page 25-21.
For the HSI service, the MSS parameter (Table 25-15) can be configured for one of the following instances of servers: Premium - Layer 4-7 Silver - Layer 4-7 Bronze - Layer 4-7
Table 25-15. HSI Service - Additional Parameters Parameter MSS (bytes) Description The maximum size of the TCP segments, expressed in bytes, sent from the server to the clients.
IPTV-A Layer 2-3 Two types of parameters are available: 1. Channel Configuration parameters: Automatic Allocation Channel on page 25-20 lists the parameters available for Automatic allocation mode. Manual Allocation Channel on page 25-20 shows you how to allocate channels manually. 2. Traffic Configuration parameters (Table 25-17 on page 25-20).
25-19
25

Setting Up the Test
Automatic Allocation Channel If Automatic mode is chosen for the Channel Allocation parameter, you should configure the parameters listed in Table 25-16.
Table 25-16. IPTV-A Layer 2-3 - Channel Configuration - Automatic Allocation Parameter No Channels Group Address Start Group Address Step Source Address Start Source Address Step Description The number of channels for sending multicast streams The starting IP address for the multicast group The step used to increment the group IP addresses The source IP address for the multicast streams The step used to increment the source IP addresses
Manual Allocation Channel If choosing Manual mode for the Channel Allocation parameter, you should specify the Multicast Group IP addresses and the Multicast Source IP addresses. To add one or multiple multicast groups, use the Add button. A default IP address is set for the Multicast group and for the Multicast Source. If you want to change any of them, double-click the parameter field and enter the desired IP address. If the IP address is invalid, a warning displays in that parameter field. If you decide to delete a multicast group, select it from the list and click the Remove button. Traffic Configuration Parameters Table 25-17 lists the Traffic Configuration parameters available for both automatic and manual channel allocation modes.
Table 25-17. IPTV-A Layer 2-3 - Traffic Configuration Parameters Parameter DSCP 802.1p Bandwidth Description Set the DSCP byte used for the multicast stream Set the VLAN priority used for the multicast stream Set the bandwidth allocated for one channel
25-20

Setting Up the Test
IPTV-AD Layer 4-7 Table 25-18 lists the additional parameters that can be configured for the IPTVAD layer 4-7 server.
Table 25-18. IPTV-AD Layer 4-7 - Additional Parameters Parameter Layer 4-7 A-Server No Channels Multicast Group Address Start Multicast Group Address Step Layer 4-7 D-Server Burst Size (sec) Transport Bit Rate (Mbps) The rate at which the packets are sent on the video streams (both on the unicast and the multicast, depending on which stream is active). The duration of the unicast stream sent by the DServer The number of channel used The IP address for the first multicast group The incrementing step for the multicast groups IP addresses Description
IPTV-V Layer 4-7 Table 25-19 lists the additional parameters that can be configured for the IPTV-V layer 4-7 server.
Table 25-19. IPTV-V Layer 4-7 - Additional Parameters Parameter Duration (sec) Description Specify the period of time, expressed in seconds (s), for the video stream. The default value is 30. The minimum value that can be set is 0, and the maximum value is 2147483. Bit Rate (Mbps) The rate at which the packets are sent on the video streams.
25-21
25

Setting Up the Test
Client/Server Port Mapping

The Client/Server Port Mapping tab (Figure 25-5) allows you to configure the traffic map for your test. The mapping for client/server to Ixia ports is created from the tree-like interface.
Figure 25-5. Client/Server Port Mapping
Three panes are available: the left pane contains the list with the devices that you have added on the client side (in the Client Traffic tab) and on the server side (in the Server Traffic tab). They are grouped into two categoriesclients and serversand each of these category is also grouped depending on the type of traffic used. the middle pane contains the list with the hardware resources (chassis) to which you are connected. IxAutomate organizes chassis, cards, and ports hierarchically. You can use similar controls to expand (the plus sign, +) and collapse (the minus sign, -) items. the right pane contains the traffic map used when running the test.
To create the traffic map: 1. Select a device or server from the left pane.
IMPORTANT: Each client device must be assigned to a different Ixia port. Only multiple layer 2-3 servers can be added to the same physical port.
2. Select a port from the middle pane. 3. Click Add. 4. If you want to add more than 1 item in the traffic map list, repeat the steps 1 to 3.
25-22

Setting Up the Test
If you decide to delete one or multiple items (to select multiple items, hold down the CTRL key) from the traffic map list, click the Remove button.
The Test Setup window allows you to configure the test parameters (Table 2520).
Table 25-20. Test Setup Parameters Parameter Duration No. of Trials No. of Iterations Description The duration of the test in hours (hrs), minutes (min), and seconds (s). The number of trials to repeat the whole set of iterations. The default value is 1. The total number of iterations to run the test. It may be necessary to run several iterations in order to test the network characteristics (the default value is 8). The starting user percentage value for the first iteration. It determines the xDSL subscribers per device, considering the configured value in the Client Traffic tab (xDSL Subscribers parameter) as representing 100%. The value for the users per services is computed depending on the configured percentages within a device. This value is also used in the last iteration of the test, for network recovery testing. The default value is 50. An example of calculation: User % From = 50; xDSL Subscribers = 100 (in Client Traffic tab, Devices table); Users (%) = 20 (in Client Traffic tab, Traffic Profiles table); The number of users used in the first iteration is calculated as follows: 50% from 100 = 50 users per service, then 20% from 50 users = 10 users per traffic profile.
Users % From
25-23
25

Setting Up the Test
Table 25-20. Test Setup Parameters (Continued) Parameter Users % To Description The end user percentage value used for the iteration before the last iteration. In the last iteration, the users percentage is equal with the value set in the Users % From parameter field. If the value is the same for both Users % From and Users % To parameters, the user percentage value is constant throughout all iterations. The default value is 100. An example of calculation: User % To = 80; xDSL Subscribers = 100 (in Client Traffic tab, Devices table); Users (%) = 20 (in Client Traffic tab, Traffic Profiles table); The number of users used in the first iteration is calculated as follows: 80% from 100 = 80 users per service, then 20% from 80 users = 16 users per traffic profile. Bandwidth % From The starting bandwidth percentage value used for the first iteration. The bandwidth is increased in equal steps until the Bandwidth % To value is reached. If the two values are equal, then the bandwidth level is constant throughout all iterations. This value is also used in the last iteration of the test, for network recovery testing. The default value is 80. Bandwidth % To The end bandwidth percentage value used for the iteration before the last iteration. In the last iteration, the bandwidth percentage is equal with the value set in the Bandwidth % From parameter field. If the value is the same for both Bandwidth % From and Bandwidth % To parameters, the bandwidth percentage value is constant throughout all iterations. The default value is 150. Framesize % From The starting frame size percentage used for the first iteration (the framesize percentage is extracted from the frame size value configured in Client Traffic tab, Traffic Profile table). The frame size is increased in equal steps until the Framesize % To value is reached. If the two values are equal, then the frame size is constant throughout all iterations. This value is also used in the last iteration of the test, for network recovery testing. The default value is 50.
25-24

Pass/Fail Criteria
Table 25-20. Test Setup Parameters (Continued) Parameter Framesize % To Description The end frame size percentage value used for the iteration before the last iteration. In the last iteration, the frame size percentage is equal with the value set in the Framesize % From parameter field. If the value is the same for both Framesize % From and Framesize % To parameters, the frame size percentage value is constant through all the iterations. The default value is 100. Use VLAN for nCPE user tracking Flow tracking in the Triple Play Scalability test is based on service identifier and user identifier, for all services, except for the IPTV multicast service. For IPTV multicast, the tracking is based on service identifier and channel identifier. When emulating a DSLAM, the DSLAM acts as a multicast proxy and receives each channel only once. In nCPE model, we are simulating users that are physically behind xDSL modems. In this case, it is possible to have two users watching the same channel. If we used the channel identifier for flow tracking, we would receive more packets for channels watched by more than one user, which would result in wrong fairness measurements. In nCPE model, the user VLAN should be different for each user, allowing us to track flows based on service identifier and VLAN ID. This type of tracking gives correct fairness measurements and is enabled when Use VLAN for nCPE user tracking is checked. B/W Printer If you enable this check box, the PDF report is printed in black and white.
Pass/Fail Criteria
Table 25-21. Triple PLay Scalability Test - Pass/Fail Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Depending on the type of the configured clients or servers (layer 2/3 or layer 4/7), the corresponding pass/fail criteria parameters are enabled. Layer 2/3 Criteria (All Services Average)
25-25
25

Pass/Fail Criteria
Table 25-21. Triple PLay Scalability Test - Pass/Fail Criteria (Continued) Parameter Frame Loss (%) Description The percentage of transmitted frames that were lost by the DUT. The compared value represents the aggregated value calculated using each configured traffic service type (HSI, VoIP, VoD and IPTV). Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeds the number you entered. Max Delay (ms) The maximum latency value, measured in milliseconds (ms). The compared value represents the aggregated value calculated using each configured traffic service type (HSI, VoIP, VoD, and IPTV). Pass: The maximum delay value is less than or equal to the number you entered. Fail: The maximum delay value exceeds the number you entered. User Unfairness This parameter gives a measure of the per-user quality of each service (for the same service, if one user receives less packets than the average). The compared value represents the aggregated value calculated using each configured traffic service type (HSI, VoIP, VoD, and IPTV). Pass: The user unfairness value is less than or equal to the number you entered. Fail: The user unfairness value exceeds the number you entered. Layer 4/7 Criteria HSI Service HTTP Requests Failed (req/s) The rate of the failed requests, expressed in requests per second. Pass: The number of failed HTTP requests is less than or equal to the number you entered. Fail: The number of failed HTTP requests exceeds the number you entered. Latency (ms) Amount of time required by the DUT to forward frames, expressed in milliseconds (ms). Pass: The latency is less than or equal to the time you specified. Fail: The latency exceeds the time you specified. Layer 4/7 Criteria VoIP Service Failed Calls (calls/s) The rate of the failed calls, expressed in calls per second. Pass: The number of failed calls is less than or equal to the number you specified. Fail: The number of failed calls exceeds the number you specified.
25-26

Pass/Fail Criteria
Table 25-21. Triple PLay Scalability Test - Pass/Fail Criteria (Continued) Parameter Jitter Max (ms) Description The largest jitter (average latency), expressed in milliseconds (ms). Pass: The maximum jitter is less than or equal to the number you specified. Fail: The maximum jitter exceeds the number you specified. MOS The score for all calls. You can select either of these two methods to calculate the MOS: Average: The test selects the lowest average MOS value experienced (VoIP_server or VoIP_client) to determine whether a trial passed or failed. Minimum: The test selects the lowest minimum MOS value experienced, then applies the criteria to determine whether a trial passed or failed. Pass: The MOS value exceeded the value you specified. Fail: The MOS value was less than or equal to the value you specified. Layer 4/7 Criteria IPTV Service Zapping Failure Rate The percentage of failed zaps from the total number of zaps, expressed in zaps per second. Pass: The number of failed zaps is less than or equal to the number you specified. Fail: The number of failed zaps exceeds the number you specified.
25-27
25

Test Cycle
Table 25-21. Triple PLay Scalability Test - Pass/Fail Criteria (Continued) Parameter Leave Latency Description The time elapsed between the time that the client sends the multicast leave message and the time it receives the response. You can select either of these two methods to calculate the leave latency time: Average: The test selects the average latency value experienced for the service, then applies the criteria to determine whether a trial passed or failed. Maximum: The test selects the maximum latency value experienced for the service, then applies the criteria to determine whether a trial passed or failed. Pass: The leave latency was less than or equal to the time you specified. Fail: The leave latency exceeded the time you specified. Join Latency The time elapsed between the time that the client sends the multicast join message and the time it receives the response. You can select either of these two methods to calculate the latency: Average: The test selects the average latency value experienced for the service, then applies the criteria to determine whether a trial passed or failed. Maximum: The test selects the maximum latency value experienced for the service, then applies the criteria to determine whether a trial passed or failed. Pass: The join latency was less than or equal to the time you specified. Fail: The join latency exceeded the time you specified.
Test Cycle
After configuring the test in the IxAutomate GUI, you are ready to run the test (use the Start button from the tool bar or the Start option from the Run menu). The test starts by connecting to the chassis, configuring all ports, and setting up port speeds, modes, and addresses. Once the transmit and receive ports are configured, the test starts the first iteration. After the set clients and servers are configured, some additional time is allowed (5 s) before starting to transmit frames. The traffic and service characteristics used in the first iteration are those set as starting values. For example, the user percentage, the bandwidth, and the framesize used are those set in the User % From, Bandwidth % From, and Framesize % From parameter fields. When finishing the frames transmission, the test allows two seconds for any additional frames to come in. When the additional time expires, the test starts collecting statistics.
25-28

Test Results
If you specified more than one trial, the test restarts, using the same parameter values. Each time the test repeats, it collects the statistics. After all the trials complete, the test ends or, if you specified more iterations, it restarts with different values for the traffic and service parameters. They range from the starting values during the first iteration, to the end values during the iteration before last, in order to test the network limits (for example, the bandwidth parameter ranges through the Bandwidth % From and Bandwidth % To values). For the last iteration, the test uses the values for the traffic and service parameters that were used for the first iteration, in order to check if the network recovers from possible overload conditions generated during the previous iteration. The test continues until all the trials complete. It then gathers statistics and prints the results.
Test Results
Three types of test results are available: Layer 2-3 Traffic Statistics on page 25-29 Layer 4-7 Traffic Statistics on page 25-30 User CSV Files on page 25-33
Layer 2-3 Traffic Statistics
Table 25-22 describes the Layer 2-3 traffic statistics for the Scalability test.
Table 25-22. Triple Play Layer 2-3 Traffic Statistics Parameter Transmit Rate (bps) Ethernet Throughput (bps) Ethernet Throughput Per User (bps) IP Goodput Per User (bps) Frame Loss (%) Description The transmit rate expressed in bits per second (b/s) The throughput for Ethernet frames, expressed in bits per second (b/s) The throughput for Ethernet frames, for each user The throughput for the IP packets per each user (the packets do not contain the Ethernet headers) The rate of the lost frames, expressed as a percentage of the total sent frames
Unavailable Time (ms) The interval of time while a network resource is unavailable. It is calculated according to the formula: <number_of_lost_frames>/<transmission_rate> User Unfairness This parameter gives a measure of the per-user quality of each service (for the same service, if one user receives less packets than the average). It is calculated according to the formula: Avg (Number of Packets Received per User) Min (Number of Packets Received per User) /Avg (Number of Packets Received per User).
25-29
25

Test Results
Table 25-22. Triple Play Layer 2-3 Traffic Statistics (Continued) Parameter Max Delay (ms) Packet Delay Variation Average Allocation Buffer Size (bytes) IP Flows per Service (flow) Out of Order Packets Flooded Frames Rx Frames Per Service Rx Frames Per All Services Rx Frames Misdirected Flows Description The maximum latency for all packets, measured in milliseconds (ms) The difference between the maximum delay measured and the minimum delay measured The value calculated according to the formula: (Average Delay)* (Transmission Rate) The number of successful connections for a service, per port The out-of-order received packets (sequence checking) The number of flooded frames The number of received frames per service The number of received frames for all services The number of total received frames The difference between the number of received packets that were sent from the testing device and the number of packets received that belong to a flow The difference between the number of packets received on a port and the number of received packets that were sent from the testing device
Unknown Packets
Layer 4-7 Traffic Statistics
Table 25-23 describes the Layer 4-7 HSI service statistics for the Scalability test. HSI service statistics are presented independently on the upstream and the downstream and they are filtered on each emulated type of traffic profiles: premium, silver, and bronze.
Table 25-23. Triple Play Layer 4-7 HSI Service Statistics Parameter HTTP Requests Successful (req/s) HTTP Requests Failed (req/s) Latency (ms) Table The rate of the successful requests, expressed in requests per second The rate of the failed requests, expressed in requests per second The period of time, expressed in milliseconds, (ms) between sending the first byte and receiving the first byte from the server
25-30

Test Results
Table 25-23. Triple Play Layer 4-7 HSI Service Statistics (Continued) Parameter Goodput (kbytes/s) HTTP Simulated Users Table The data rate across the DUT during the test The number of users simulated during the test
Table 25-24 describes the Layer 4-7 VoIP service statistics for the Scalability test both for the client and server side.
Table 25-24. Triple Play Layer 4-7 VoIP Service Statistics Parameter Successful calls (calls/s) Failed calls (calls/s) Successful calls Failed calls Avg MOS Min MOS Max MOS Jitter Min (ms) Jitter Max (ms) Lost Packets SIP INVITE Transactions Failed (TIMER B) SIP INVITE Transactions Failed (Timer H) SIP INVITE Transactions Failed (Transport Error) SIP INVITE Transactions Failed (Transaction timeout Timer) SIP INVITE Transactions Failed (5xx) SIP NON-INVITE Transactions Failed (Timer F) Description The rate of the successful calls The rate of the failed calls The total number of the successful calls The total number of the failed calls The average score for all calls The lowest score during the test The highest score during the test The lowest jitter The largest jitter The number of the lost RTP packets The number of initiated INVITE transactions that failed because Timer B (transaction timeouts timer) expired (VoIP client specific) The number of initiated INVITE transactions that failed because Timer H (wait time for ACK receipt) expired (VoIP server specific) The number of initiated INVITE transactions that failed due to TCP or UDP errors The number of initiated INVITE transactions that failed because the transaction timeout timer expired (VoIP client specific) The number of initiated INVITE transactions that failed due to 5xx-service (server error) errors (VoIP client specific) The number of NON-INVITE transactions that failed because Timer F (non-INVITE transaction timeout timer) expired (VoIP client specific)
25-31
25

Test Results
Table 25-24. Triple Play Layer 4-7 VoIP Service Statistics (Continued) Parameter SIP NON-INVITE Transactions Failed (Transport Error) Unknown Type Failures Description The number of NON-INVITE transactions that failed due to TCP or UDP errors The difference between the total number of failures and the sum of all known failures mentioned above
Table 25-25 describes the Layer 4-7 IP-TV service statistics for the Scalability test.
Table 25-25. Triple Play Layer 4-7 IP-TV Service Statistics Parameter Successful Zapping Rate (zaps/s) Failed Zapping Rate (zaps/s) Zapping Failure Rate Successful Zaps Failed Zaps Simultaneous BTV Viewers Max/Min/Avg Leave Latency Max/Min/Avg Join Latency Max/Min/Avg MDI DF (ms) Unicast - Multicast Switch Latency (ms) Unicast DESCRIBE Failed Description The rate of the successful zaps The rate of the failed zaps The percentage of failed zaps from the total number of zaps The number of the successful zaps The number of the failed zaps The number of the users zapping at the same time The time elapsed between the time that the client sends the multicast leave message and the time it receives the response The time elapsed between the time that the client sends the multicast join message and the time it receives the response The largest/smallest/average media Delay Index Delay Factor experienced on stream. The time elapsed between the arrival of the first unicast packet and the arrival of the first multicast packet The number of RTSP DESCRIBE commands that failed
Unicast SETUP Failed The number of RTSP SETUP commands that failed Unicast PLAY Failed The number of RTSP PLAY commands that failed
Table 25-26 describes the Layer 4-7 Video service statistics for the Scalability test.
25-32

Test Results
Table 25-26. Triple Play Layer 4-7 Video Service Statistics Parameter Max/Min/Avg MDI-DF (ms) MDI - MLR Description The largest/smallest/average Media Delay Index Delay Factor experienced on stream Media Delay Index Media Loss Rate experienced on stream
User CSV Files
For each port enabled for Layer 2-3 traffic, an additional information file is generated (*port*_user.csv). It contains detailed per user/per iteration information. Each user stream that contributes to the traffic on the targeted port is described in the generated file.
Table 25-27. User CSV Files - Parameters Description Parameter Iteration User ID MAC IP User VLAN Transmitted Frames Received Frames Lost Frames Flooded Frames Min Delay (ms) Avg Delay (ms) Max Delay (ms) Sequence Errors Description The iteration number The computed user ID (depends on service) Assigned MAC address Assigned IP address Assigned User VLAN The number of transmitted frames sent by a particular user The number of received frames by a particular user The number of lost frames that were transmitted by a particular user The number of frames received beyond the number of expected frames for that particular user The minimum latency for packets sent by that particular user The average latency for packets sent by that particular user The maximum latency for packets sent by that particular user The sequence errors recorded on user data stream
25-33
25

Test Results
25-34
26
Chapter 26:
Enhanced Quality of Service Test Suite
This chapter describes the tests in the Enhanced Quality of Service (Enhanced QoS) test suite and covers the following topics: Setting Up the Tests on page 26-2. Layer 2 QoS Test on page 26-7. This test determines DUT/SUT Layer 2 performance by setting up and sending multiple streams across a Layer 2 connection. It uses the VLAN Priority field to differentiate the latency and throughput between different classes of service. Layer 3 QoS Test on page 26-11. This test determines DUT/SUT Layer 3 performance by setting up and sending multiple streams across a Layer 3 connection. It uses DSCP (Differentiated Service Code Point) or ToS (Type of Service) to differentiate the latency and throughput between different classes of service. MPLS OSPF QoS Test on page 26-16. This is an MPLS test that uses the MPLS experimental bits to differentiate the latency and throughput between different classes of service. The test allows you to configure multiple Ixia interfaces with IP addresses and gateways. On each interface, a directly connected router running OSPF and LDP is emulated. Additionally, further OSPF/LDP routers are simulated behind each directly connected router. OSPF advertisements are used to simulate a grid of routers and LDP is used to announce a label for each routers loopback FEC. The test verifies if the OSPF and LDP are successfully established and if the correct labels are learned. MPLS QoS Test on page 26-21. This is an MPLS test that uses the MPLS experimental bits to differentiate the latency and throughput between different QoS classes of service. The test allows you to configure multiple Ixia interfaces with IP addresses and gateways. On each interface, a directly connected router running OSPF and LDP is emulated. OSPF announces a router LSA (Link State Advertisement) with loopback interface, LDP (Label Distribution Protocol) announces a label for the loopback FEC (Forwarding Equivalency Class). The test verifies if the
26-1
26

OSPF and LDP are successfully established and if the correct labels are learned.

Most of the Enhanced QoS tests parameters are common to many IxAutomate tests and work the same way for all of them. Each test description includes a description of the parameters that are unique for that test. For the common run parameters, see Test Setup Parameters on page 26-5. The Traffic Setup parameters are not common to the other IxAutomate tests; for the traffic parameters common to the Enhanced QoS tests, see Traffic Setup Parameters on page 26-2. Each test description includes a description of the parameters that are unique for that test.
The Traffic Setup parameters are available in two different tabs: Interface Groups it allows you to create and configure the interfaces used in the test. For more information, see Interface Groups Settings on page 26-2. Traffic Maps it allows you to define the transmit/receive relationship between the configured interfaces. For more information, see Traffic Maps on page 26-4.
Interface Groups Settings

This tab contains controls for creating and configuring the interfaces to use in the test. It contains two areas: 1. A configured interfaces groups list; each interface group must have only one port selected. 2. A pane containing tabs for selecting the ports used in the current interface group and for configuring the parameters of the current interface group. The common tabs are: Ports tab it contains a list of the available ports. VLAN tab it contains the configurable parameters for VLAN protocol. Table 26-1 describes these parameters.
26-2

Table 26-1. Parameter VLAN Mode
Enhanced QoS Tests - VLAN Parameters Description You can choose the VLAN mode for your test from the following options: disabled no VLAN encapsulation single VLAN encapsulation stacked VLAN encapsulation
Outer Label TPID
If you choose single or stacked VLAN encapsulation, you can set the Tag Protocol Identifier (TPID) to identify the frame as an IEEE 802.1Q-tagged frame. If you choose single or stacked VLAN encapsulation, you can set the VLAN priority by the current interface group. If you choose single or stacked VLAN encapsulation, you can set the Canonical Form Indicator (CFI) to indicate the frame IEEE 801.1p priority level. If you choose single or stacked VLAN encapsulation, you can set the first VLAN ID by the current interface group. If you choose single or stacked VLAN encapsulation, you can set the number of VLANs by the current interface group. If you choose single or stacked VLAN encapsulation, you can set the VLAN ID increment step between the VLAN IDs by the current interface group. If you choose stacked VLAN encapsulation, you can set the Tag Protocol Identifier (TPID) to identify the frame as an IEEE 802.1Q-tagged frame. If you choose stacked VLAN encapsulation, you can set the inner VLAN priority by the current interface group. If you choose stacked VLAN encapsulation, you can set the Canonical Form Indicator (CFI) to indicate the frame IEEE 801.1p priority level. If you choose stacked VLAN encapsulation, you can set the first inner VLAN ID by the current interface group. If you choose stacked VLAN encapsulation, you can set the number of inner VLANs by the current interface group. If you choose stacked VLAN encapsulation, you can set the inner VLAN ID increment step between the VLAN IDs by the current interface group.
Outer Label User Priority Outer Label CFI
Outer Label VLAN ID
Outer Label Number of VLANs Outer Label Increment Step Inner Label TPID
Inner Label User Priority Inner Label CFI
Inner Label VLAN ID
Inner Label Number of VLANs Inner Label Increment Step
26-3
26

IPv4 tab it contains the configurable parameters for the IPv4 protocol. Table 26-2 describes these parameters.
Table 26-2. Parameter IP Address Enhanced QoS Tests - IPv4 Parameters Description It allows you to configure the IP addresses for the Layer 3 endpoints emulated by the current interface group. It allows you to configure the network mask of the Layer 3 endpoints emulated by the current interface group. It allows you to configure the gateway address of the Layer 3 endpoints emulated by the current interface group. It allows you to configure the number of Layer 3 endpoints emulated by the current interface group. It allows you to configure the IP address increment step between the Layer 3 endpoints emulated by the current interface group.
Mask
Gateway Address
Number IP Addresses IP Increment Step
Traffic Maps
This tab contains controls for creating and configuring the traffic flow between the interfaces configured in the Interface Groups tab. It contains two areas: 1. A configured traffic maps list; each traffic map must be configured with: A source interface group A destination interface group 2. A panel (Frame Settings tab) allowing you to configure different parameters. The common parameters are described in Table 26-3.
Table 26-3. Parameter Frame Properties Frame Size Traffic Rate The size of the frames of the traffic generated by the current traffic map. The transmission rate of the generated traffic. The rate can be defined in terms of: line rate percents (%) packets per second (pps) kilobits per second (kbps) Bursting Enhanced QoS Tests - Frame Settings Description
26-4

Table 26-3. Parameter Enabled
Enhanced QoS Tests - Frame Settings Description If you check this box, you can specify the Inter Burst Gap and the Inter Packet Gap used by the current traffic map. Allows you to set the inter burst gap value, expressed in seconds. The default value is 1.
Inter Burst Gap
Burst Count Mpls QoS Setting Exp bits
The number of burst to send during the test.
Allows you to set the experimental bits from the MPLS label.
The Test Setup parameters are available in two different tabs: General Settings it allows you to create and configure the interfaces used in the test. For more information, see General Settings on page 26-5. Statistics it allows you to define the transmit/receive relationship between the configured interfaces. For more information, see Statistics on page 26-6.
General Settings
Table 26-4 describes the common parameters available in the General Settings tab.
Table 26-4. Parameter Test Parameters Test Search Duration The duration of the test, in hours, minutes, and seconds, that is used to calculate the number of frames that need to be transmitted. The duration of the protocol timeout, in hours, minutes, and seconds. The number of trials to run. It may be necessary to run several trials of the tests in order to verify the results for consistency. Enhanced QoS Tests - General Settings Parameters Description
Protocol Timeout No. of Trials
Iterative Controls Test Iterations Rate Increment (%) Set the number of iterations to run. Set the transmission rate increment between two successive iterations.
26-5
26

Enhanced QoS Tests - General Settings Parameters Description
Learning Frames Learn Frequency Choose how frequently IxAutomate sends learning frames during the test. Once per Test: IxAutomate sends learning frames only once, at the beginning of the test. Once per Framesize: IxAutomate sends learning frames each time it begins testing with a new frame size. On Trial: IxAutomate sends learning frames at the beginning of each trial. On Iteration: IxAutomate sends learning frames at the beginning of each iteration. Never: IxAutomate never sends learning frames.
Statistics
Table 26-5 describes the common parameters available in the Statistics tab.
Table 26-5. Parameter Statistics Settings Latency/Jitter Sequence Checking Choose to calculate the Latency or the Jitter of the transmitted traffic. If you check this box, the test includes the following types of sequence errors in the results: Small Sequence Errors: Number of packets received with small sequence errors. A small sequence error occurs when the expected sequence number minus the previous sequence number is less than or equal to the error threshold (set by the software) and not negative, or when the expected sequence number is equal to the previous sequence number. Big Sequence Errors: Number of packets received with large sequence errors A large sequence error occurs when the expected sequence number minus the previous sequence number is greater than the error threshold. Reverse Sequence Errors: Number of packets received with reverse sequence errors A reverse sequence error occurs when the expected sequence number is less than the previous sequence number. Sequence Errors: Combined total of packets with sequence errors of all types Enhanced QoS Tests - Statistics Description
26-6

Layer 2 QoS Test
Enhanced QoS Tests - Statistics (Continued) Description If you check this box, the test calculates the data integrity for the generated traffic.
Data Integrity Latency Bin Settings Bin Mode
Choose what bins to configure: Disabled: no latency bins can be configured Latency: latency bins can be configured
No. of Bins
Set the number of latency bins when Bin Mode is set to Latency.
Layer 2 QoS Test

This section covers the following topics: Overview of the Layer 2 QoS Test on page 26-7. Test Cycle on page 26-8. Supported Protocols on page 26-8. Test Setup: Run Parameters on page 26-8. Pass Criteria on page 26-9. Test Results on page 26-11.
Overview of the Layer 2 QoS Test
This test determines DUT/SUT Layer 2 performance by setting up and sending multiple streams across a Layer 2 connection. It uses the VLAN priority field to differentiate latency and throughput between different classes of service. This test supports MAC frames; priority bits may be specified in the VLAN Priority parameter field. The number of flows is governed by the number of MAC addresses specified. The number of MAC addresses (flows) is automatically distributed over the number of configured VLANs.
Note: The number of Tx VLANs is based on the Rx configuration.
This test uses a one-to-one traffic mapping and the traffic is unidirectional.
26-7
26

Layer 2 QoS Test
Enhanced QoS Layer 2 QoS

Ixia TX Ports Ixia RX Ports
Example of VLAN ID Assignment First VLAN ID : Tx Port 1: Tx Port 2: No of VLANs per Port Rx Port 1: Rx Port 2: 11 1,1,1 1,1,2 2 1,1,3 1,1,4
DUT
Port 1,1,1 1,1,2 Assigned VLAN ID 11, 12 13, 14
Traffic Map Port (VLAN ID) Tx 1,1,1 (11) 1,1,1 (12) 1,1,2 (13) 1,1,2 (14) Rx 1,1,4 1,1,4 1,1,3 1,1,3
Figure 26-1. Enhanced QoS - Layer 2 QoS Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also, the MAC learning frames are sent so that the DUT can learn the Ixia ports addresses and the Ixia ports learn the DUTs addresses. Once the transmit and receive ports are configured, the streams are transmitted. After transmitting all the streams, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports and then prints the results.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port Layer2-MAC, VLANs Advanced Scheduler Mode Receive port Wide Packet Group Mode
For information about the common settings for the Enhanced QoS tests, see Traffic Setup Parameters on page 26-2. Table 26-6 contains the configurable parameters for the Layer-2 MAC protocol that are different from the standard settings or unique for this test.
26-8

Layer 2 QoS Test
Enhanced QoS Tests - MAC Parameters Description Allows you to set the number of Layer 2 endpoints emulated by the current interface group. Allows you to set the MAC address increment step between the Layer 2 endpoints emulated by the current interface group. If you enable this option, you can explicitly configure the source MAC address of the Layer 2 endpoints emulated by the current interface group. If the Source Override Enabled check box is enabled, you can specify the explicit source MAC address of the Layer 2 endpoints emulated by the current interface group. If you enable this option, you can explicitly configure the destination MAC address of the Layer 2 endpoints emulated by the current interface group. If the Destination Override Enabled check box is enabled, you can specify the explicit destination MAC address of the Layer 2 endpoints emulated by the current interface group.
Number Source Addresses Address Step
Source Override Enabled Source
Destination Override Enabled Destination
For more information about the common run parameters, see Test Setup Parameters on page 26-5. For information about other tests in this family, see Enhanced Quality of Service Test Suite on page 26-1. For further information about IxAutomate testing in general, see Creating and Running IxAutomate Tests on page 3-1.
Pass Criteria
26-9
26

Layer 2 QoS Test
L2 QoS Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The acceptable percentage of lost frames from the traffic forwarded by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of data errors over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of data errors experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of lost frames was equal to or less than the number you entered. Fail: The number of lost frames was greater than the number you entered.
Pass Criteria
Loss (%)
Loss Duration (sec)
The acceptable loss duration, expressed in seconds (s). You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of loss seconds over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of loss seconds experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of loss seconds was equal to or less than the number you entered. Fail: The number of loss seconds was greater than the number you entered.
Total Sequence Errors The maximum acceptable amount of sequence errors. Pass: The number of total sequence errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total sequence errors introduced by the DUT was greater than the number you entered. Total Data Integrity Errors The maximum acceptable amount of data integrity errors. Pass: The number of total data errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total data errors introduced by the DUT was greater than the number you entered.
26-10

Layer 3 QoS Test
Test Results
In addition to the standard IxAutomate test results, this test also reports (per flow): Tx rate and Rx rate, in %, pps and kbps Flow Tx frames and flow Rx frames Frame Loss Loss Duration
If Sequence Checking is enabled, the following results are available: Small Sequence Errors Big Sequence Errors Reverse Sequence Errors
If Data Integrity is enabled, the following results are available: Data Integrity Errors
If the Latency/Jitter parameter field is set to Latency, the following results are available: MinLatency (us) MaxLatency (us) the value is rounded up to the nearest millisecond (ms) AvgLatency (us)
If the Latency/Jitter parameter field is set to Jitter, the following results are available: Latency Standard Deviation (Jitter) (us)
If the Bin Mode parameter field is set to Latency, the number of frames received in the specified latency bins are available.
Note: If some packets from a flow are received on a different port than the one to which they were destinedthat is, the DUT floods packets, the message Rx Pkts-Wrong Port is returned.
Layer 3 QoS Test

This section covers the following topics: Overview of the Layer 3 QoS Test on page 26-12. Test Cycle on page 26-12. Supported Protocols on page 26-12. Test Setup: Run Parameters on page 26-13. Pass Criteria on page 26-14. Test Results on page 26-15.
26-11
26

Layer 3 QoS Test
Overview of the Layer 3 QoS Test
This test determines DUT/SUT Layer 3 performance by setting up and sending multiple streams across a Layer 3 connection. It uses DSCP (Differentiated Service Code Point) or ToS (Type of Service) to differentiate latency and throughput between different classes of service. This test supports IP frames; priority bits may be specified in the Binary Value parameter field. The test allows you to configure multiple Ixia interfaces with IP addresses, gateways, and optionally, with single VLAN and stacked VLANs. This test uses a one-to-one traffic mapping and the traffic is unidirectional.
Enhanced QoS Layer 3 QoS

Example of VLAN ID Assignment First VLAN ID: Tx Port 1: Tx Port 2: No of IP streams per Port Rx Port 1: Rx Port 2: 11 1,1,1 1,1,2 2 1,1,3 1,1,4
DUT
Port 1,1,1 1,1,2
Rx 1,1,4 1,1,4 1,1,3 1,1,3
Assigned ToS or DSCP 000001, 000011 000111, 001111
Traffic Map Tx 1,1,1 (000001) 1,1,1 (000011) 1,1,2 (000111) 1,1,2 (001111)
Figure 26-2. Enhanced QoS - Layer 3 QoS Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also, the ARP frames are sent so that the DUT can learn the Ixia port addresses. Multiple interfaces can be set for each Ixia port. Each IP interface may be used as a base address and thousands of entries can be derived per entry. The base IP flow characteristics can be replicated for all flows. Generate IP streams and streams with VLAN tags. Once the transmit and receive ports are configured, the streams are transmitted. After transmitting all the streams, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports and then prints the results.
Supported Protocols
26-12

Layer 3 QoS Test
Supported Protocols
Features Required on Ports Transmit port Receive port Wide Packet Group Mode
IP, VLANs
Advanced Scheduler Mode
For information about the common settings for the Enhanced QoS tests, see Traffic Setup Parameters on page 26-2. Table 26-8 lists the Traffic Maps settings that are different from the standard settings or unique for this test.
Table 26-8. Parameter Layer 3 QoS Settings Enabled QoS Header If you check this box, IxAutomate allows you to specify the QoS configurations used by the current traffic map. You can choose the QoS mechanism used by the current traffic map: DSCP (Differentiated Service Code Point) ToS (Type of Service) Binary Value You can set the binary value of the ToS/DSCP bits. MPLS OSPF QoS Test - Traffic Maps Settings Description
TCP/UDP Port Settings Enabled If you check this box, IxAutomate allows you to specify the Layer 4 protocol configurations used by the current traffic map. You can choose the Layer 4 protocol used by the current traffic map: TCP UDP Source Port Destination Port It allows you to configure the source port used by the current traffic map. It allows you to configure the destination port used by the current traffic map.
Port Type
For more information about the common run parameters, see Test Setup Parameters on page 26-5. For information about other tests in this family, see Enhanced Quality of Service Test Suite on page 26-1.
26-13
26

Layer 3 QoS Test
Pass Criteria

Table 26-9. Parameter Pass Criteria L3 QoS Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The acceptable percentage of lost frames from the traffic forwarded by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of data errors over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of data errors experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of lost frames was equal to or less than the number you entered. Fail: The number of lost frames was greater than the number you entered. Loss Duration (sec) The acceptable loss duration, expressed in seconds (s). You can select either of two methods to calculate the percentage of frames lost: Average/Flow: The test averages the number of loss seconds over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of loss seconds experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of loss seconds was equal to or less than the number you entered. Fail: The number of loss seconds was greater than the number you entered.
Loss (%)
26-14

Layer 3 QoS Test
L3 QoS Test - Pass Criteria (Continued) Description
Total Sequence Errors The maximum acceptable amount of sequence errors. Pass: The number of total sequence errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total sequence errors introduced by the DUT was greater than the number you entered. Total Data Integrity Errors The maximum acceptable amount of data integrity errors. Pass: The number of total data errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total data errors introduced by the DUT was greater than the number you entered.
Test Results
26-15
26

MPLS OSPF QoS Test
MPLS OSPF QoS Test

This section covers the following topics: Overview of the OSPF QoS Test on page 26-16. Test Cycle on page 26-16. Supported Protocols on page 26-17. Test Setup: Run Parameters on page 26-17. Pass Criteria on page 26-19. Test Results on page 26-20.
Overview of the OSPF QoS Test
This is an MPLS test that uses the MPLS experimental bits to differentiate latency and throughput between different classes of service. This test allows you to configure multiple Ixia interfaces with IP addresses and gateways. On each interface, a directly connected router running OSPF and LDP is emulated. Additionally, further OSPF/LDP routers are simulated behind each directly connected router. OSPF advertisements are used to simulate a grid of routers and LDP is used to announce a label for each routers loopback FEC. The test verifies if the OSPF and LDP are successfully established and if the correct labels are learned. This test uses a one-to-one traffic mapping and the traffic is unidirectional.
Enhanced QoS MPLS OSPF QoS

Tx Port 1: Tx Port 2: No of IP streams per Port Rx Port 1: Rx Port 2: 1,1,1 1,1,2 2 1,1,3 1,1,4
DUT
Port 1,1,1 1,1,2
Assigned MPLS Exp Bits 001, 010 110, 111
Traffic Map Tx 1,1,1 (001) 1,1,1 (010) 1,1,2 (110) 1,1,2 (111) Rx 1,1,4 1,1,4 1,1,3 1,1,3
Figure 26-3. Enhanced QoS - MPLS OSPF QoS
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also, the ARP frames are sent so that the DUT can learn the Ixia ports addresses. Once the ports are configured, the LDP and OSPF protocols come up, then the MPLS and/or IP flows are transmitted between Ixia emulated routers as per the
26-16

MPLS OSPF QoS Test
flow configuration file. MPLS flows can be configured with a variable number of MPLS labels. After transmitting all the streams, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports and then prints the results.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port MPLS, OSPF, IPv4 Advanced Scheduler Mode Receive port Wide Packet Group Mode
For information about the common settings for the Enhanced QoS tests, see Traffic Setup Parameters on page 26-2. Table 26-10 lists the MPLS Settings that are different from the standard settings or unique for this test.
Table 26-10. MPLS OSPF QoS Test - MPLS Settings Parameter MPLS Type Description Specify the MPLS label type from the following options: implicit Null explicit Null Custom Advertised FEC Range If the MPLS Type is set to Custom, this is used to set the MPLS label value; otherwise, this option is not available.
Table 26-11 lists the OSPF Settings that are different from the standard settings or unique for this test.
Table 26-11. MPLS OSPF QoS Test - OSPF Setup Parameter OSPF Settings OSPF Type Choose the OSPF link type for the interfaces included in the current interface group. The available options are: Point to point Broadcast Description
26-17
26

MPLS OSPF QoS Test
Table 26-11. MPLS OSPF QoS Test - OSPF Setup (Continued) Parameter Hello Interval Dead Interval Authentication Description The period of time when the updates are sent over the network The period of time to wait for the updates to be sent over the network Configure the OSPF authentication mechanism for the interfaces contained in the current interface group. The available options are: Null means no authentication MD5 MD5-based authentication Password password-based authentication Key/Password If an authentication mechanism is used, you can configure the MD5 key/password, depending on the selected authentication mechanism.
MTU Settings MTU Validation Enable MTU Size If this option is enabled, the MTU is validated during the OSPF database exchange process. When the MTU Validation Enable option is checked, you can configure the maximum MTU size on the OSPF interface; otherwise, the MTU size is considered 0.
LSA Route Generators LSA1 (Link State Advertisement 1) If you enable the corresponding check box, you can generate the configured number of type 1 LSAs. The routes contained in the type 1 LSAs are used as destination endpoints. LSA3 (Link State Advertisement 3) LS5 (Link State Advertisement 5) LSA10 (Link State Advertisement 10) If you enable the corresponding check box, you can generate the configured number of type 3 LSAs. These routes are used only to generate OSPF routes. If you enable the corresponding check box, you can generate the configured number of type 5 LSAs. These routes are used only to generate OSPF routes. If you enable the corresponding check box, you can generate the configured number of type 10 LSAs. These routes are used only to generate OSPF opaque LSAs.
Routing Looping IP Address If you enable the corresponding check box, you can configure the router ID of the emulated router generating the type 1 LSAs and type 5 LSAs. It is also used as the link ID of the type 1 LSAs.
26-18

MPLS OSPF QoS Test
Table 26-11. MPLS OSPF QoS Test - OSPF Setup (Continued) Parameter External Advertising Router ID Opaque LSA ID Description If you enable the corresponding check box, you can configure the router ID of the emulated router generating the type 3 LSAs. If you enable the corresponding check box, you can configure the router ID of the emulated router generating the type 10 LSAs. It is also used as the link ID of the type 10 LSAs.
Pass Criteria

Table 26-12. MPLS OSPF QoS Test - Pass Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The acceptable percentage of lost frames from the traffic forwarded by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of data errors over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of data errors experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of lost frames was equal to or less than the number you entered. Fail: The number of lost frames was greater than the number you entered.
Loss (%)
26-19
26

MPLS OSPF QoS Test
Table 26-12. MPLS OSPF QoS Test - Pass Criteria Parameter Loss Duration (sec) Description The acceptable loss duration, expressed in seconds (s). You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of loss seconds over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest numbers of loss seconds experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of loss seconds was equal to or less than the number you entered. Fail: The number of loss seconds was greater than the number you entered. Total Sequence Errors The maximum acceptable amount of sequence errors. Pass: The number of total sequence errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total sequence errors introduced by the DUT was greater than the number you entered. Total Data Integrity Errors The maximum acceptable amount of data integrity errors. Pass: The number of total data errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total data errors introduced by the DUT was greater than the number you entered.
Test Results
In addition to the standard IxAutomate test results, this test also reports (per flow): Tx rate and Rx rate, in %, pps, and kbps Flow Tx frames and flow Rx frames Frame Loss Loss Duration
26-20

MPLS QoS Test
MPLS QoS Test

This section covers the following topics: Overview of the MPLS QoS Test on page 26-21. Test Cycle on page 26-22. Supported Protocols on page 26-22. Test Setup: Run Parameters on page 26-22. Pass Criteria on page 26-23. Test Results on page 26-25.
Overview of the MPLS QoS Test
This is an MPLS test that uses the MPLS experimental bits to differentiate latency and throughput between different classes of service. The test allows you to configure multiple Ixia interfaces with IP addresses and gateways. On each interface, a directly connected router running OSPF and LDP is emulated. OSPF announces a router LSA (Link State Advertisement) with loopback interface, LDP (Label Distribution Protocol) announces a label for the loopback FEC (Forwarding Equivalency Class). The test verifies if the OSPF and LDP are successfully established and if the correct labels are learned. This test uses a one-to-one traffic mapping and the traffic is unidirectional.
26-21
26

MPLS QoS Test
Enhanced QoS MPLS QoS

Tx Port 1: Tx Port 2: No of IP streams per Port Rx Port 1: Rx Port 2: 1,1,1 1,1,2 2 1,1,3 1,1,4
DUT
Traffic Map Tx 1,1,1 (001) 1,1,1 (010) 1,1,2 (110) 1,1,2 (111) Rx 1,1,4 1,1,4 1,1,3 1,1,3
Port 1,1,1 1,1,2
Assigned MPLS Exp Bits 001, 010 110, 111
Figure 26-4. Enhanced QoS - MPLS QoS Test
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, and configuring the ports that you set. Also, the ARP frames are sent so that the DUT can learn the Ixia ports addresses. Once the ports are configured, the LDP and OSPF protocols come up, then the MPLS and/or IP flows are transmitted between Ixia emulated routers as per the flow configuration file. MPLS flows can be configured with a variable number of MPLS labels. After transmitting all the streams, the test collects statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports and then prints the results.
Supported Protocols

Supported Protocols Features Required on Ports Transmit port MPLS, OSPF, IPv4 Advanced Scheduler Mode Receive port Wide Packet Group Mode
For information about the common settings for the Enhanced QoS tests, see Traffic Setup Parameters on page 26-2. Table 26-13 lists the Protocol Setup settings that are different from the standard settings or unique for this test.
26-22

MPLS QoS Test
Table 26-13. MPLS QoS Test - Protocol Setup Parameter OSPF Settings OSPF Type Choose the OSPF link type for the interfaces included in the current interface group. The available options are: Point to point Broadcast Hello Interval Dead Interval Authentication The period of time when the updates are sent over the network The period of time to wait for the updates to be sent over the network Configure the OSPF authentication mechanism for the interfaces contained in the current interface group. The available options are: Null means no authentication MD5 MD5-based authentication Password password-based authentication Key/Password If an authentication mechanism is used, you can configure the MD5 key/password, depending on the selected authentication mechanism. Description
MPLS Settings MPLS Type Specify the MPLS label type from the following options: implicit Null explicit Null Custom Advertised FEC Range If the MPLS Type is set to Custom, this is used to set the MPLS label value; otherwise, this option is not available.
Pass Criteria
26-23
26

MPLS QoS Test
Table 26-14. MPLS QoS Test - Pass Criteria Parameter Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. The acceptable percentage of lost frames from the traffic forwarded by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of data errors over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of data errors experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of lost frames was equal to or less than the number you entered. Fail: The number of lost frames was greater than the number you entered. Loss Duration (sec) The acceptable loss duration, expressed in seconds (s). You can select either of these two methods to calculate the percentage of lost frames: Average/Flow: The test averages the number of loss seconds over a flow, then applies the criteria to determine whether a trial passed or failed. Maximum/Flow: The test selects the largest number of loss seconds experienced on each flow, then applies the criteria to determine whether a trial passed or failed. Pass: The number of loss seconds was equal to or less than the number you entered. Fail: The number of loss seconds was greater than the number you entered. Total Sequence Errors The maximum acceptable amount of sequence errors. Pass: The number of total sequence errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total sequence errors introduced by the DUT was greater than the number you entered. Total Data Integrity Errors The maximum acceptable amount of data integrity errors. Pass: The number of total data errors introduced by the DUT was equal to or less than the number you entered. Fail: The number of total data errors introduced by the DUT was greater than the number you entered.
Loss (%)
26-24

MPLS QoS Test
Test Results
26-25
26

MPLS QoS Test
26-26
27
Chapter 27:
Internet Infrastructure Test Suite
This chapter describes the test present in the Internet Infrastructure test suite. IxAutomate includes the following test: IP Mesh Test on page 27-1 This test determines the maximum throughput that the DUT can support while receiving and transmitting unicast and/or multicast frames over a preconfigured BGP network.
IP Mesh Test
This section covers the following topics: Overview of the IP Mesh Test on page 27-1. Test Cycle on page 27-2. Traffic Setup Parameters on page 27-4. Supported Protocols on page 27-6. Run Parameters on page 27-6. Protocol Parameters on page 27-7. Pass Criteria on page 27-9. Test Results on page 27-10.
Overview of the IP Mesh Test
The DUTs throughput is calculated while receiving and transmitting unicast and/or multicast frames over a preconfigured BGP network. It allows you to calculate the maximum DUT throughput using either a binary or a linear search, and to collect latency and data integrity statistics. A fully-meshed traffic mapping is used for unicast traffic and a many-to-many traffic mapping is used for multicast traffic. Figure 27-1 on page 27-2 shows the flow traffic diagram for this test.
27-1
27

IP Mesh Test
Internet Infrastructure - IP Mesh

Ixia TX Ports
Simulated Network Routes
Ixia RX Ports
Simulated BGP Router
Simulated Multicast Groups
DUT
BGP Router
Simulated BGP Router Simulated Multicast Groups
Note: The Ixia Tx Ports are multicast ports. Routes to simulated network Unicast traffic destined for simulated network Multicast traffic
Figure 27-1. IP Mesh Traffic Flow Diagram
Test Cycle
The test starts by connecting to the chassis, creating the unicast and multicast port mappings for the test, and configuring the ports that you set. For unicast traffic: If the test uses IPv4 unicast traffic or IPv6 unicast traffic over IPv4 peers, the ports send ARP frames at the configured rate so that the DUT can learn the Ixia ports addresses. If the test uses IPv6 unicast traffic over IPv6 peers, the neighbor discovery process is performed.
If the Enable ARP option is checked, the test performs ARP for all the ports from the multicast traffic map. The multicast receive ports send Join requests to the DUT. The setting of the IGMP Version determines the format of the Join messages. The First Group Address and Group Addresses per Rx Port parameters determine the groups that the multicast receive ports try to join. The First Group Address is the address of the first multicast group to be used and Group Addresses per Rx Port is the number of group addresses to assign to each multicast Rx port. When Custom Distribution group type is selected, you can configure the Total No. of Group Addresses parameter. The test allocates the addresses to join according to the value that you specified for Group Type:
27-2

IP Mesh Test
Distributed means that each group per Rx port has a different IP address on every multicast port; Accumulated means that each group per Rx port has the same IP address on every multicast port; Custom Distribution means that the test decides which Tx ports transmit to which multicast groups and which Rx port joins which multicast group. The number set for the Total No. of Group Addresses should divide by the number set for the Group Addresses per Rx Port parameter and also the Total No. of Group Addresses should divide by the number of Tx ports.
After configuring the unicast and multicast streams, the test begins initiating the BGP simulation on all ports set in the unicast traffic map. The test polls the DUT once per second for an acknowledgement that it has established its own BGP session. For each iteration specified, the test starts a timer and begins advertising the route prefixes of the simulated BGP networks to the DUT for each frame size. Once all the routes have been advertised to the DUT, the test transmits Imix frames (specified by Frame Size) from each port to the routes in the simulated networks in a fully-meshed manner. After transmitting all the frames, the test collects statistics on how many of the transmitted packets were forwarded by the DUT to the receive ports, also calculates the throughput and the latency.The linear or binary search is used to calculate the DUT throughput. The Search Type parameter determines how the maximum throughput is calculated: Binary Search algorithm description if a port pair drops frames, it searches downwards for a lower rate. If a port pair does not drop frames, it searches upwards for a higher rate. To choose a lower rate, the test divides the previous range in half, and uses the result as the new rate. To find a higher rate, it divides the previous range in half and adds it to the previous rate. The test searches among higher and lower rates until it finds the rate, within the specified tolerance, at which no frames are lost. If Linear Search is used, the initial iteration value and the iteration increment value are configurable.
The BGP sessions stop after printing statistics for each iteration. If you set more than one frame size, the test restarts. Each time the test repeats, it calculates the DUT throughput and the latency. After all frame sizes for the specified trial are complete, the test either ends or, if you specified more than one trial, it restarts. The test continues until all trials and frame sizes are complete. It then gathers statistics on the number of transmitted and lost packets, throughput, and latency values.
27-3
27

IP Mesh Test
The Traffic Setup window contains two different tabs, allowing you to set up the: Unicast Parameters on page 27-4. Multicast Parameters on page 27-5.
Note: The Ixia Tx Ports are Multicast Tx ports; the Ixia Rx Ports are Multicast Rx ports.
Unicast Parameters
The Unicast Parameters tab allows you to set up: 1. Frame size: only the IMIX mode is available. For more information about setting the frames using the Imix frame size mode, see Chapter 3, Imix Mode. An option is added, allowing you to set the number of transmitted frames by bandwidth percentage or by weight. You can choose from the BW(%)/ Weight Column Caption available drop-down list one of these two options: Bandwidth Percent or Weight The name for the BW(%)/Weight column changes according to your choice. Traffic Map: See Setting Up the Traffic Map on page 3-11. The traffic can be sent only bidirectionally in Automatic mode. IMPORTANT: The Exclude ports option is applied independently for each type of map (unicast traffic map and multicast traffic map). Additionally, if the Assign Addresses to excluded ports check box is enabled for the unicast traffic map, the common ports for both maps use IP addresses configured in the unicast map. Protocol: See Configuring IP Addresses on page 3-25 and Configuring IPv6 Addresses on page 3-32.
Table 27-1 describes the Frame Data parameters from the Unicast Parameters tab.
Table 27-1. Parameter Frame Data Assign Addresses to Excluded Ports It allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports. IP Mesh Frame Data - Unicast Parameters Description Description
Protocol: IP Tester IP Address Specify the first IP address.
27-4

IP Mesh Test
IP Mesh Frame Data - Unicast Parameters Description (Continued) Description Specify the mask used to increment the IP address for the Ixia ports. Specify the first IP address for the gateway. Specify the mask used to increment the IP address for the gateway. If you enable this option, you can set the octet to increment for the Gateway IP Address. Specify the octet to increment.
Subnet Mask Gateway IP Address Subnet Mask Enable Gateway IP Address Increment Increment Gateway Address By Protocol: IPv6 Tester IPv6 Address Subnet Mask Gateway IPv6 Address Subnet Mask Enable Gateway IPv6 Address Increment Increment Gateway IPv6 Address By
Specify the first IPv6 address. Specify the mask used to increment the IPv6 address for the Ixia ports. Specify the first IPv6 address for the gateway. Specify the mask used to increment the IPv6 address for the gateway. If you enable this option, you can set the octet to increment for the Gateway IPv6 Address. Specify the octet to increment.
Multicast Parameters
The Multicast Parameters tab allows you to set up: 1. Frame size: Specify the size of the frames to transmit. For more information about frame sizes, see Choosing Frame Sizes on page 3-45. Learning Frames: See Configuring ARP and IGMP on page 9-7. Protocol: See Configuring IP Addresses on page 3-25. The Assign Addresses to Excluded Ports option allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports. Traffic Map: See Setting Up the Traffic Map on page 3-11. The traffic map used for this test is many-to-many and only the Automatic mode is available.
27-5
27

IP Mesh Test
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6, IGMPv1,2,3, IBGP, EBGP Packet Streams mode Receive port Capture mode
Run Parameters
Table 27-2 lists the run parameters for this test.

Table 27-2. Field Duration IP Mesh Test - Run Parameters Usage The duration of the test in hours, minutes, and seconds, which is used to calculate the number of frames that need to be transmitted. Select the number of times that you want the test to run. If you check this box, the test calculates the latency. If this option is enabled, the intrinsic latency of the port is subtracted from the measured latency values. IMPORTANT: This option is available only if you use at least IxOS 5.10. Staggered Transmit If you check this box, IxAutomate introduces a 25-30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, you can use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time. Detailed Results If you check this box, detailed results are available when the test run ends. For each unicast port, the Rx Port, ToS, and Route information is available. For each multicast port, the Tx port, Rx port, and Group information is available. Fast Statistics Processing If you check this option, only one iteration per trial/ frame size is used to calculate the throughput, the Pass Criteria are not available and the Detailed Results option is enabled; minimum settings are available in order to obtain fast statistics.
No. of Trials Calculate Latency Calibrate Latency
27-6

IP Mesh Test
Table 27-2. Field
IP Mesh Test - Run Parameters (Continued) Usage If you enable this option, IPv4 unicast traffic is sent. If you enable this option, IPv6 unicast traffic is sent. If you enable this option, multicast traffic is sent. The algorithm used to calculate the throughput. The available options are Binary Search and Linear Search. This parameter is available only for the linear search algorithm and represents the number of iterations per trial/frame size to run the test. You may need to run several iterations in order to test the network characteristics (the default value is 1). This parameter is available only for the binary search algorithm and represents the difference between the transmission rate in two consecutive iterations. When the difference is smaller than the specified value, the test stops.
Send IPv4 Unicast Traffic Send IPv6 Unicast Traffic Send Multicast Traffic Search Type
No. of Iterations
Resolution
Loss Tolerance
This parameter is available only for the binary search algorithm and represents the percentage of total packets allowed to be lost before declaring that an iteration is successful. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
Load Rate
Load is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s) percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which frames are transmitted for the ports.
Increment
Specify the increase value (positive value) or decrease value (negative value) in the transmission rate for each iteration. This parameter is available only for the linear search algorithm.
Protocol Parameters
Table 27-3 lists the protocol parameters for this test.

Table 27-3. Parameter BGP Parameters BGP Type BGP Protocol: IBGP (Internal BGP) or EBGP (External BGP). IP Mesh Test - Protocol Parameters Description
27-7
27

IP Mesh Test
IP Mesh Test - Protocol Parameters (Continued) Description The Autonomous System number associated with the simulated BGP router. For EBGP, the initial set value is automatically incremented by one; for IBGP, the initial value remains fixed. The number of emulated routers per each Ixia port. The number of prefixes advertised by each emulated router. Increments the IP addresses between peers on the same port. The first IP address of the advertised prefixes The number of bits in the mask to use in creating the range of addresses. It increments the IP addresses between routes on the same peer. Increments the IP addresses across routes between different peers. Increments the IPv6 addresses between peers on the same port. The first IPv6 address of the advertised prefixes The number of bits in the mask to use in creating the range of addresses. It increments the IPv6 addresses between routes on the same peer. Increments the IPv6 addresses across routes between different peers. For IPv6 unicast traffic, you can choose IPv4 or IPv6 peers to advertise IPv6 routes. The time, in seconds (s), for the BGP sessions to come up The time, in seconds (s), allowing the DUT enough time to finish the BGP setup at the beginning of the test before actually starting to transmit the test traffic
Local AS Number
Number of Peers per Port Number of Routes per Peer Increment Peer IP Address By First Route Subnet Mask
Increment Across Routers Increment Peer IPv6 Address By First Route Subnet Mask
Increment Across Routers IPv4/IPv6 Peers BGP Sessions Delay DUT Processing Delay
Route Advertise Delay The maximum time, in seconds (s), to allow the router to absorb all routes Multicast Parameters IGMP Version First Group Address The IGMP version to use: 1, 2, or 3 IP address of the first multicast group
27-8

IP Mesh Test
Table 27-3. Parameter Group Type
IP Mesh Test - Protocol Parameters (Continued) Description Determines how addresses are allocated among ports: If you select Accumulated, each group per Rx port has the same IP address on every multicast port. If you select Distributed, each group per Rx port has a different IP address on every multicast port. If you select Custom Distribution, the test decides which Tx ports transmits to which multicast groups and which Rx port joins which multicast group.
Total Number of Group Addresses
This option is configurable only for the Custom Distribution Group Type; otherwise, the value is calculated by the test. IMPORTANT: 1. The value for the Group Addresses per Rx Port and the number of Tx ports should divide by the value set for the Total No. of Group Addresses parameter. 2. The value set for the Total No. of Group Addresses parameter should be less or equal to number of Rx Ports * Group Addresses per Rx Port. If any of the two conditions above is not met, the test is aborted at runtime.
Group Addresses per Rx Port
The number of group addresses to be assigned to each receive port. During the test, each port joins this number of groups starting with the group specified by the First Group Address parameter. The number of frames per second sent for the Join/ Leave messages If you check this box, the hosts simulated by the Ixia port send IGMP Leave Group messages to the DUT at the end of the test. Sets the IP header Send Router Alert bit in messages.
Join/Leave Rate (fps) Enable Leave Group
Enable Router Alert
Pass Criteria
27-9
27

IP Mesh Test
IP Mesh - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the load rate over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest load rate experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Pass Criteria
Load Rate
Latency
Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was lower than or equal to the time you specified. Fail: The latency exceeded the time you specified.
Test Results
For each type of traffic, a result file is available: an IPv4unicast results file, an IPv6 unicast results file, and a Multicast results file. In addition to the standard IxAutomate test results, the following results are available: Frame count TxTput in f/s and % AvgLatency MinLatency
27-10

IP Mesh Test
MaxLatency Data Errors Frame Loss
27-11
27

IP Mesh Test
27-12
28
Chapter 28:
Fibre Channel over Ethernet Test Suite

Overview of the Fibre Channel over Ethernet Test Suite on page 28-1.
IxAutomate includes the following FCoE tests: FCoE Performance Test on page 28-2. This test determines the maximum throughput that the DUT can support while receiving and transmitting FCoE traffic and/or non-FCoE traffic and also the latency. Mixed Class Throughput Test on page 28-29. This test performs RFC 2544 throughput testing of mixed class traffic, FCoE and non-FCoE traffic. The non-FCoE traffic consists of multicast and unicast traffic. PFC Throughput Test on page 28-34. This test is similar to the FCoE Performance test except: In addition, the binary search algorithm uses pause frames to determine pass/fail criteria. Flow control is always enabled.
Overview of the Fibre Channel over Ethernet Test Suite

Fibre Channel over Ethernet (FCoE) is a newly-proposed standard that is being developed by INCITS T11. Both Ethernet for TCP/IP networks and Fibre Channel (FC) for storage area networks (SANs) are used, each dedicated to specific purposes: Ethernet networks are generally implemented when end users need to transfer relatively small amounts of information over both local and global distances.
28-1
28

FCoE Performance Test
Storage area networks are implemented for applications that require a higher amount of data such as: mail servers, file servers, and large databases. For these, the use of SANs is necessary.
Conceptually, FCoE can be broken down into three components: Encapsulation of a native fibre channel frame into an Ethernet frame The extension of Ethernet to become a lossless fabric The replacement of a fibre channel link with MAC addresses in a lossless Ethernet fabric
The advantage of using fibre channel frames over Ethernet is that it provides lossless transport.

The test determines DUT performances while receiving and transmitting FCoE traffic and/or non-FCoE traffic. It allows you to calculate the maximum DUT throughput using either a binary or a linear search, and to collect latency and data integrity statistics. Four types of traffic map can be set both for automatic and manual map configuration: one-to-one, many-to-one, one-to-many, or partially meshed. Figure 28-1 shows the traffic flow diagram for this test.
Ixia Tx Ports
FCoE Performance
Ixia Rx Ports
Simulated NPIV Interfaces
Simulated N_Port Interfaces
DUT
FCoE traffic
Non-FCoE traffic
Note: The NPIV interfaces can be simulated on any of the simulated N_Port interfaces.
Figure 28-1. Performance Test - Traffic Flow Diagram
This section covers the following topics: Test Cycle on page 28-3.
28-2

Traffic Setup Parameters on page 28-3. Supported Protocols on page 28-11. Run Parameters on page 28-11. FCoE Advanced Parameters on page 28-14. LLDP/DCBX Parameters on page 28-17. Pass Criteria on page 28-20. Test Results on page 28-22.
Test Cycle
After configuring the test in the IxAutomate GUI, you are ready to run the test (use the Start button from the tool bar or the Start option from the Run menu). The test starts by connecting to the chassis, creating the port mappings for the test, configuring all ports and setting up port speeds, modes, and addresses. If you choose to simulate FCoE and/or non-FCoE interfaces on the ports, the interfaces are configured. For the non-FCoE traffic, if the IP protocol is set, the ARP requests are sent; if the MAC protocol is set, the MAC learning frames are sent. For the FCoE traffic, the discovery requests are sent. Once the transmit and receive ports and the simulated interfaces are configured, the test starts the first iteration. After the streams are configured, the traffic is transmitted for the specified period of time. When finishing the frames transmission, the test allows two seconds for any additional frames to come in. When the additional time expires, the test starts collecting statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports. The binary or linear search algorithm can be used to calculate the DUT throughput. Additionally, the latency can be calculated for the test. If the FCoE traffic is enabled, the test performs the linear or binary search using the first frame size; if you specified more than one frame size, the test restarts the search using the next one. If the non-FCoE traffic is enabled, it uses the same frame size for all iterations. If you specified more than one trial, the test restarts, using the first frame size. For each iteration, the test calculates the DUT throughput, latency, and frame loss percentage. The test continues until all trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost frames. After gathering statistics, it prints the results.
The Traffic Setup window contains two different tabs, allowing you to set up the: Non-FCoE Parameters on page 28-4.
28-3
28

FCoE Parameters on page 28-4.
Non-FCoE Parameters
The Non-FCoE Parameters tab allows you to set up: Frame size: The Performance test allows you to select and test different frame sizes. Standard, Automate, and Manual frame sizes are available. If you specify multiple frame sizes, test iterations are based on two frame size loops, the outer one for Ethernet and the inner one for FCoE. For more information about frame sizes, see Choosing Frame Sizes on page 3-45. Traffic Map: See Setting Up the Traffic Map on page 3-11. The traffic can be sent unidirectionally and bidirectionally both for the Manual and Automatic mode. Protocol: See Configuring IP, IPX, and MAC Addresses on page 3-18, Configuring IP Addresses on page 3-25, and Configuring IPv6 Addresses on page 3-32. The Assign Addresses to Excluded Ports option allows you to assign IP addresses to the ports excluded from the automatic traffic map, even if they are not used when running the test. This option is added to help with better address distribution for different tests with different excluded ports. VLAN Parameters: See Setting the VLAN Parameters on page 3-42.
Table 28-1 describes the parameters from the Non-FCoE tab that are unique for this test.
Table 28-1. Parameter Enable Non FCoE Traffic PFC Group Increment By VLAN User Priority Increment By Performance Test Non-FCoE Description Description If you check this box, the settings for the non-FCoE traffic are applied when running the test. Specify the priority group number. It can be mapped to the priority field in the frame. Increments PFC Group between ports. The user priority of the VLAN tag (a value from 0 through 7). Increments VLAN user priority between ports.
FCoE Parameters
The FCoE Parameters tab allows you to set up: Frame size: Specify the size of the frames to transmit. For more information about frame sizes, see Choosing Frame Sizes on page 3-45. IMPORTANT: The Standard mode starts from a list of frame sizes defined by RFC 2544, but the FCoE drafts specify that only frame sizes multiple of 4 are used and the maximum frame size for the FCoE traffic is 2176.
28-4

Discovery Parameters: Table 28-2 describes the parameters available in this section.
Performance Test - Discovery Parameters Description The number of retries to send discovery requests (default = 5). Specify the rate at which IxAutomate sends discovery requests. The default value is set to 500.
Table 28-2. Parameter Retries
Request Rate
Traffic Map: The FCoE traffic setup section allows you to configure the traffic maps. The mapping can be configured at the interface level, not at port level. Multiple interfaces can be assigned on each port. For further information, see Traffic Map Parameters on page 28-5.
Traffic Map Parameters For both Manual and Automatic mode: Four types of traffic maps can be set: one-to-one, many-to-one, one-to-many, or partially meshed; The traffic can be sent unidirectionally and bidirectionally.
NOTES: 1. When the Automatic traffic map is used:
all the transmitting ports have the same number of source interfaces and all the receiving ports have the same number of destination interfaces. the transmitting ports should not overlap with the receiving ports (make sure that you do not configure source interfaces and destination interfaces on the same port at the same time).
2. When the Manual traffic map is used:
a different number of source and destination interfaces are allowed on each port any source interface can transmit to any destination interface you are not allowed to configure source and destination interfaces on the same port at the same time.
3. When NPIV virtual interfaces are used, only 1 N_Port physical interface is enabled per port. The NPIV interfaces inherit FLOGI enabled and node WWN address.
Manual Map Guidelines For the FCoE traffic, choose the Manual mode and click the Configure button to display the Manual Port Map window (Figure 28-2). In the Manual Port Map
28-5
28

window, map the transmit and receive interfaces to each other (the mapping can be configured at interface level, not at port level).
Figure 28-2.Performance Test - FCoE Traffic - Manual Map Window
For each of the Source Interfaces and Destination Interfaces lists, there are three buttons available: the Add Interfaces ( ) button, which allows you to add one FCoE interface for each available port. To add an interface, select the port and click this button (only one FCoE interface can be added for each port). the Add NPIV Interfaces ( ) button, which allows you to add one or more NPIV interfaces for each newly-added FCoE interface. To add a NPIV interface, select the physical interface, then click this button. the Delete ( ) button, which allows you to remove a FCoE or NPIV interface. To delete it, first select the interface and then click the button.
NOTE: For each newly-added interface, the Interface Parameters are available in the lower window panel.
To add a manual traffic map: 1. In the Sources Interfaces panel, add the desired interfaces (FCoE and NPIV) for each transmit port. Use the corresponding buttons described above.
28-6

2. In the Destination Interfaces panel, add the desired interfaces (FCoE and NPIV) for each receive port. Use the corresponding buttons described above. 3. Hold down the CTRL key while mapping a source interface with a destination interface. 4. Click Add. IxAutomate adds the mapping and moves on to the next logical choice. 5. If you change your mind and want to delete one of the configured maps, select it in the Configured Maps list and click Remove. 6. When you finish mapping the interfaces, click Apply to create the map.
NOTES:
1. A port cannot be both a source port and a destination port at the same time. 2. You can map a NPIV interface with a FCoE interface. Source and Destination Interfaces Parameters Table 28-3 on page 28-7 lists the parameters available in the Source Interfaces section. Table 28-4 on page 28-9 lists the parameters available in the Destination Interfaces section.
Table 28-3. Parameter No. of Sources Per Port FLOGI Enable Performance Test - Source Interfaces Parameters Description Specify the number of interfaces simulated per port. Enable Fabric login (FLOGI). By default, this check box is enabled. The test does not perform discovery for configured interfaces if FLOGI is disabled. PLOGI Enable NS Registration PFC Group Increment By Buffer to Buffer Rx Size FIP Enables Port login to specified Destination ID. Enables registration to Name Server. Specify the priority group number. It can be mapped to the priority field in the frame. Increments PFC Group between interfaces. Maximum buffer-to-buffer Receive_Data_Field specified by the Fabric. When enabled, the interface uses FIP (Fibre Channel over Ethernet Initialization Protocol) for initialization. If not enabled, the Cisco Adhoc protocol is used. The default is Enabled. Options are Fabric Provided, Server Provided, or Both. the default is Fabric Provided.
Addressing Mode
28-7
28

Performance Test - Source Interfaces Parameters (Continued) Description Configures the maximum frame size for FCoE. The default is 2158 bytes. Specify the source port Worldwide Name. It represents a Name_identifier that is worldwide unique, represented by a 64-bit value. Allows you to increment the source port address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the source node Worldwide Name. It represents a Name_identifier that is worldwide unique, represented by a 64-bit value. Allows you to increment the source node address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the Source Organization Unique Identifier, 3 bytes. The one recommended (by T11 standard drafts) is 0E.FC.00, 0E.FC.01, etc.
MAX FCoE Size Port WWN
Increment
Node WWN
Increment
Source OUI
Increment
Allows you to increment the source OUI address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the Destination Identifier. Allows you to increment the destination ID address assigned to the first selected interface and assign the incremented address to the next selected interface. If selected it enables the VLAN option on this port, with one VLAN ID per interface. If FPMA is the addressing mode, select this option to enable IxOS to propose the MAC address. Select to enable FIP VLAN discovery. The first VLAN ID received from an FCoE-enabled DUT is used. If the VLAN option is enabled for the current interface, a VLAN ID is added to the packet, to identify the VLAN to which the packet belongs. NOTE: If VLAN Discovery is enabled, the discovered VLAN is used instead.
Destination ID Increment
VLAN Enable Propose MAC in FPMA mode VLAN Discovery VLAN ID
User Priority
The user priority of the VLAN tag: a value ranging from 0 to 7. The use and interpretation of this field is defined in ISO/IEC 15802-3. If you enable this check box, the NPIV interfaces can be configured.
NPIV
28-8

Performance Test - Source Interfaces Parameters (Continued) Description Specify the number of NPIVs simulated per interface. Enables Port login to specified Destination ID. Enables registration to Name Server. Specify the priority group number. It can be mapped to the priority field in the frame. Increments PFC Group between interfaces. Maximum buffer-to-buffer Receive_Data_Field specified by the Fabric. Specify the source port Worldwide Name. It represents a Name_identifier that is worldwide unique, represented by a 64-bit value. Allows you to increment the source port address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the Destination Identifier. Allows you to increment the destination ID address assigned to the first selected interface and assign the incremented address to the next selected interface. The user priority of the VLAN tag: a value from 0 through 7. The use and interpretation of this field is defined in ISO/IEC 15802-3. Performance Test - Destination Interfaces Parameters Description Specify the number of interfaces simulated per port. Enable Fabric login (FLOGI). Enables Port login to specified Destination ID. Enables registration to Name Server. Specify the priority group number. It can be mapped to the priority field in the frame. Increments PFC Group between interfaces. Maximum buffer-to-buffer Receive_Data_Field specified by the Fabric. Specify the source port Worldwide Name. It represents a Name_identifier that is worldwide unique, represented by a 64-bit value.
Number of NPIVs Per Interface PLOGI Enable NS Registration PFC Group Increment By Buffer to Buffer Rx Size Port WWN
Increment
User Priority
No. of Destinations Per Port FLOGI Enable PLOGI Enable NS Registration PFC Group Increment By Buffer to Buffer Rx Size Port WWN
28-9
28

Table 28-4. Parameter Increment
Performance Test - Destination Interfaces Parameters (Continued) Description Allows you to increment the source port address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the source node Worldwide Name. It represents a Name_identifier that is worldwide unique, represented by a 64-bit value. Allows you to increment the source node address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the Source Organization Unique Identifier, 3 bytes. Allows you to increment the source OUI address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the Destination Identifier. Allows you to increment the destination ID address assigned to the first selected interface and assign the incremented address to the next selected interface. If selected it enables the VLAN option on this port, with one VLAN ID per interface. If FPMA is the addressing mode, select this option to enable IxOS to propose the MAC address. If the VLAN option is enabled for the current interface, a VLAN ID may be added to the packet, to identify the VLAN to which the packet belongs. NOTE: If VLAN Discover is enabled, the discovered VLAN is used.
Node WWN
Increment
Source OUI Increment
VLAN Enable Propose MAC in FPMA mode VLAN ID
User Priority
The user priority of the VLAN tag: a value ranging from 0 to 7. The use and interpretation of this field is defined in ISO/IEC 15802-3. If you enable this check box, the NPIV interfaces can be configured. Specify the number of NPIVs simulated per interface. Enables Port login to specified Destination ID. Enables registration to Name Server. Specify the priority group number. It can be mapped to the priority field in the frame. Increments PFC Group between interfaces. Maximum buffer-to-buffer Receive_Data_Field specified by the Fabric.
NPIV Number of NPIVs Per Interface PLOGI Enable NS Registration PFC Group Increment By Buffer to Buffer Rx Size
28-10

Table 28-4. Parameter FIP
Performance Test - Destination Interfaces Parameters (Continued) Description When enabled, the interface uses FIP (Fibre Channel over Ethernet Initialization Protocol) for initialization. If not enabled, the Cisco Adhoc protocol is used. The default is Enabled. Options are Fabric Provided, Server Provided, or Both. the default is Fabric Provided. Configures the maximum frame size for FCoE. The default is 2158 bytes. Select to enable FIP VLAN discovery. The first VLAN ID received from an FCoE-enabled DUT is used. Specify the source port Worldwide Name. It represents a Name_identifier that is worldwide unique, represented by a 64-bit value. Allows you to increment the source port address assigned to the first selected interface and assign the incremented address to the next selected interface. Specify the Destination Identifier. Allows you to increment the destination ID address assigned to the first selected interface and assign the incremented address to the next selected interface. The user priority of the VLAN tag: a value ranging from 0 to 7. The use and interpretation of this field is defined in ISO/IEC 15802-3. Allows you to increment the priority.
Addressing Mode MAX FCoE Size VLAN Discovery Port WWN
Increment
User Priority
Increment Priority
Supported Protocols

Supported Protocols Features Required on Ports Transmit port FCoE, FIP, MAC, IP, IPv6, VLAN Advanced Scheduler mode Receive port Wide Packet Group mode
Run Parameters
Two tabs are available in the Test Parameters section: Run Parameters tab Table 28-5 on page 28-12 lists the parameters available in this tab. FCoE Advanced Parameters tab Table 28-6 on page 28-14 lists the parameters available in this tab.
28-11
28

LLDP/DCBX Parameters tab Table 28-7 on page 28-18 lists the parameters available on this tab.
Performance Test - Run Parameters Usage The duration of the test in hours, minutes, and seconds, which is used to calculate the number of frames that need to be transmitted.
Table 28-5. Field Duration
Test Parameters No. of Trials Staggered Transmit Select the number of times that you want the test to run. Select to cause a 25 to 30 ms delay between the time one port begins transmitting and the time the next port begins transmitting. If not selected, all ports begin transmitting at the same time. Typically, you use staggered transmit if your DUT cannot cope with test traffic arriving on all ports at the same time. Select to generate pause frame statistics. For more information, refer to Pause Frame Results Metrics and Aggregate Pause Frame Results Metrics on page 2827. Select to generate jitter statistics (instead of sequence error statistics). NOTE: Sequence checking is disabled if this is selected. Enable Flow Control If you enable this check box, you can choose which protocol to use for the Ethernet flow control: IEEE 802.3x or IEEE 802.1Qbb. Ethernet flow control is a mechanism for temporarily stopping the transmission of data on an Ethernet computer network. IEEE 802.3x The IEEE 802.3x flow control protocol consists in: when a sending station transmits data faster than the receiving part of the network, it is possible that it cannot accept it. The overwhelmed network element sends a PAUSE frame, which halts the transmission of the sender for a specified period of time. The 802.1Qbb protocol is a priority-based flow control protocol. Priority-based flow control is intended to eliminate frame loss due to congestion. This is achieved by a mechanism similar to the IEEE 802.3x PAUSE, but operating on individual priorities.
Pause Frames Stats
Calculate Jitter
IEEE 802.1Qbb
Iteration Parameters Search Type The algorithm used to calculate the throughput. The available options are Binary Search and Linear Search.
28-12

Table 28-5. Field
Performance Test - Run Parameters (Continued) Usage This parameter is available only for the linear search algorithm and represents the number of iterations per trial/frame size to run the test. You may need to run several iterations in order to test the network characteristics (the default value is 1). This parameter is available only for the binary search algorithm and represents the percentage of total packets allowed to be lost before declaring that an iteration is successful. IxAutomate calculates loss tolerance according to the following formula: ((TX Frames - RX Frames) / TX Frames) * 100 = %
No. of Iterations
Loss Tolerance
Resolution
This parameter is available only for the binary search algorithm and represents the difference between the transmission rate in two consecutive iterations. When the difference is smaller than the specified value, the test stops.
Init Rate
Init rate is applied to the DUT by transmitting at a rate in terms of: kilobits per second (Kb/s) percentage of the maximum frame rate (%) frames per second (f/s) Set the starting rate at which the test frames are transmitted. Use caution when specifying low rates; the test can become less accurate if the frame rate nears 1 f/s.
Increment
Specify the increase value (positive value) or decrease value (negative value) in the transmission rate for each iteration. This parameter is available only for the linear search algorithm. Here you can select either a ratio of iteration rates or a fixed rate. Percentages of FCoE and non-FCoE frames within the traffic stream. The sum of the mixed traffic is always 100. Max Rate determines the speed at which the test transmits and the test applies the values for FCoE and non-FcoE to the Max Rate value. The ratios apply only for ports sending mixed traffic; the other ports send only one type of traffic and the Max Rate value. Configure the rate for the Ethernet traffic. In this mode, the Unicast rate is the same on all port that transmit Unicast traffic, included Mixed. The FCoE traffic starts with the Init rate on all ports that transmit FCoE traffic, including Mixed. The same FCoE rate is applied to all ports. Only the FCoE rate is adjusted between iterations.
Traffic Rate Mode Ratio of Iteration Rate
Fixed Rate
28-13
28

FCoE Advanced Parameters
Table 28-6 lists the FCoE Advanced parameters for this test.
NOTE: Sequence error checking is not supported in jitter mode.
Performance Test - FCoE Advanced Parameters Description
FCoE Header and Trailer Parameters FCoE Header and Trailer Version Reserved (Before ESOF) (E-SOF Delimiter) If you enable this check box, the parameters in this section become available. Configures the version (default = 0) Start-of-Frame reserved value (default = 00 00) The Start-of-Frame (SOF) delimiter is an Ordered Set that immediately precedes the frame content. There are multiple SOF delimiters defined for Sequence control. (E-EOF Delimiter) SOFn1 - Normal Class 1 or 6 SOFn2 - Normal Class 2 SOFn3 - Normal Class 3 (default) SOFn4 - Normal Class 4 SOFi2 - Initiate Class 2 SOFi3 - Initiate Class 3 SOFi4 - Initiate Class 4 SOFc4 - Connect Class 4 SOFf - Fabric
The End-of-Frame (EOF) delimiter is an Ordered Set that immediately follows the CRC. The EOF delimiter designates the end of the frame content. All frames other than the last frame of a Sequence shall be terminated with an EOFn delimiter. Valid frame content: EOFn - EOF Normal identifies the end-of-frame EOFt - EOF Terminate indicates that the Sequence associated with this SEQ_ID is complete. (default) EOFrt - EOF Remove Terminate EOFni - EOF Normal Invalid replaces an EOFn or EOFt, indicating that the frame content is invalid. EOFrti - EOF Remove Terminate Invalid EOFa (EOF Abort) terminates a partial frame due to a malfunction in a link facility during transmission.
Reserved (After EEOF)
Specifies the three reserved bytes after the End-ofFrame delimiter.
Fibre Channel Frame Header Parameters
28-14

Performance Test - FCoE Advanced Parameters (Continued) Description If you enable this check box, the parameters in this section become available. The R_CTL field is a one-byte field that contains reserved bits and information bits to categorize the frame function. When the R_CTL field is used in combination with the TYPE field, it provides an FC_Port with assistance in frame routing, data routing, or addressing. The R_CTL field is further subdivided into the RESERVED field and the INFORMATION field. Frame Types: Device_Data frames Extended Link Services FC-4 Link_Data Video_Data Extended_Headers Basic Link Services Link_Control Frame Extended Routing
Fibre Channel Frame Header R_CTL
CS_CTL/Priority
Class Specific Control/Priority (00 or 01) When set to 00, it is interpreted to be CS_CTL information (containing management information for the class of service identified by the SOF). When set to 01,it is interpreted to be Priority information (containing priority information for the class of service identified by the SOF).
Type
The data structure type is a one-byte field that identifies the protocol of the frame content for Data frames. When R_CTL = Basic or Extended Link_Data: 00 = Basic Link Service 01 = Extended Link Service 01 to CF = Reserved D0 to FF = Vendor Specific When R_CTL = Video_Data: 02 to 5F = Reserved 60 = FC-AV Container 61 = ARINC 818 62 to 63 = Reserved for FC-AV 64 to CF = Reserved D0 to FF = Vendor Specific
28-15
28

Performance Test - FCoE Advanced Parameters (Continued) Description When R_CTL = Device_Data and Link_Data: 00 to 03 = Reserved 04 = Obsolete 05 = IPv4, IPv6, and ARP over Fibre Channel 06 to 07 = Reserved 08 = Fibre Channel Protocol (see FCP-3) 09 = Obsolete 0A to 0F = Reserved - SCSI 10 = Reserved 11 to 13 = Obsolete 14 = Fibre Channel SATA Tunnelling Protocol (see FC-SATA)
SEQ_ID
The SEQ_ID is a one-byte field assigned by the Sequence Initiator that shall be unique for a specific D_ID and S_ID pair while the Sequence is open. The Originator Exchange_ID is a two-byte field that identifies the Exchange_ID assigned by the Originator of the Exchange. Each Exchange is assigned an identifier unique to the Originator or OriginatorResponder pair. The Parameter field has different meanings based on the frame type. For Link_Control frames, the Parameter field is used to carry information specific to the individual Link_Control frame. For data frames with the relative offset present bit set to 1, the Parameter field specifies the relative offset. For data frames with the relative offset present bit set to 0, the Parameter field is set and interpreted in a protocol specific manner that may depend on the type of Information Unit carried by the frame.
OX_ID
Parameter
Bad FC CRC
When checked, it ensures that the inner FC CRC that is generated by the hardware is to be wrong. If not checked, then the FC CRC should be a valid CRC. You can either fill in this three-byte field that contains the address identifier of the source Nx_Port or click the From Interfaces check box so that the value is supplied. Enabled by default, indicates that S_ID for all tx interfaces is supplied by the discovery protocol. Disabling it allows the user to manually set the S_ID value. You can either fill in this three-byte field that contains the address identifier of the source Nx_Port or click the From Interfaces check box so that the value is supplied.
S_ID
From Interface
D_ID
28-16

Performance Test - FCoE Advanced Parameters (Continued) Description Enabled by default, indicates that S_ID for all tx interfaces is supplied by the discovery protocol. Disabling it allows the user to manually set the S_ID value. Frame Control is a three-byte field that contains control information relative to the frame content. Data Field Control (DF_CTL) is a one-byte field that specifies the presence of optional headers at the beginning of the Data_Field. The Originator Exchange_ID is a two-byte field that identifies the Exchange_ID assigned by the Originator of the Exchange. Each Exchange is assigned an identifier unique to the Originator or OriginatorResponder pair. The sequence count is a two-byte field that indicates the sequential order of Data frame transmission within a single Sequence or multiple consecutive Sequences for the same Exchange. The SEQ_CNT of the first Data frame of the first Sequence of the Exchange transmitted by either the Originator or Responder is binary zero. The SEQ_CNT of each subsequent Data frame in the Sequence is incremented by one.
From Interface
F_CTL DF_CTL
OX_ID Counter
SEQ_CNT
RX_ID
The Responder Exchange_ID is a two byte field assigned by the Responder that provides a unique, locally meaningful identifier at the Responder for an Exchange established by an Originator and identified by an OX_ID.
Traffic Mode Mapping 4 Priority Traffic Mapping 8 Priority Traffic Mapping Enables 4 PFC mode on the ports used in the test. Supports only four PFC queues, with frame size 64 to 9K bytes on all four. Enables 8 PFC mode on the ports used in the test. Supports eight PFC queues, with frame size 64 to 9K bytes on first PFC and a frame size limit of 2500 on the others.
LLDP/DCBX Parameters
Table 28-7 lists the LLDP/DCBX parameters for this test.
28-17
28

Performance Test - LLDP/DCBX Parameters Description Select to enable LLDP/DCBX. Select to print the LLDP/DCBX discovered information to a log.
Enable LLDP/DCBX Enable LDP/DCBX Log LLDP Params Enable Fast Transmit
Enable Fast Transmit. The interval for the LLDP transmission time to refresh the timer (Tx Interval) is set to 1 second for the first five transmissions after LLDP initialization, and then reset to the value you configure. Minimum delay between successive transmitted LLDP frames. DCBX default = 2 seconds. MAC address of the chassis. Enabled by default. Indicates that Chassis ID for all DCBX interface is supplied by the interface configuration. Disable to manually set the Interface Name value. Select MAC Address or Interface Name. Type the MAC address or interface name. Enabled by default. Indicates that Interface Name for all DCBX interface is supplied by the interface configuration. Disable to manually set the Interface Name value. 4 Tx Hold is the multiplier on Tx Interval that determines the actual TTL that is sent in the LLDP message. Hold Time X Tx Interval = TTL
TX Delay Chassis Id From Interface
Port Id Sub Type Interface Name From Interface
Hold Time
Tx Interval
If Fast Transmit is enabled, the interval for the LLDP transmission time to refresh the timer (msgTxInterval) is set to 1 second for the first five transmissions after LLDP initialization, and then reset to the value you configure. Hold Time X Tx Interval = TTL
DCBX Params DCBX OUI The OUI used for the DCBX TLV is 0x001B21. The default is the Intel OUI, but you can change it to any 3byte value. Either Intel 1.0 or IEEE 1.01. The TLV differs depending on your selection. Highest DCBX protocol version supported by the system (0 through 255).
DCBX Sub Type TLV Max Version
28-18

Performance Test - LLDP/DCBX Parameters Description To add a DCBX feature type, select it from the list on the left and click Add. To configure a feature type, select it from the list on the right and click Configure. Depending on the feature type you select, the appropriate dialog box appears. To remove a feature type from the test, select it from the list on the right and click Remove. Max Version 255, in all cases. Enable Select to enable the TLV. Willing Select if this feature accepts its configuration from the peer. Subtype For Logical Link: 0 = FCoE, 1 = LAN For negative testing or other purposes, use any value. Default = 0.
DCBX Feature Type
Fields common to all Feature Values
Intel 1.0 Priority Group configuration
Priority User priority. BWG ID Queue bandwidth group. Strict priority settings: 0 = no strict priority, 1 = Group Strict Priority (GSP), 2 = Link Strict Priority (LSP). BW% Percentage of BWG bandwidth. BWG ID BWG to which the priority belongs. BWG% Percentage of link bandwidth. User Priority Map Select a priority. User Priority Map Select a priority associated with the FCoE traffic. Logical Link Status Specify whether the Logical Link Status of this type of network (FCoE or LAN) is up or down.
Intel 1.0 PFC configuration Intel 1.0 FCoE configuration Intel 1.0 Logical Link configuration
28-19
28

Performance Test - LLDP/DCBX Parameters Description Enter the 16-bit header field definition: Type of TLV (integer) 1 = PROTOCOL Control (not a feature), 2 = Priority Groups, 3 = Priority Flow Control, 4 = BCN, 5 = Application, 6 = Logical Link Down Length (integer) Length of the DCB Feature subTLV payload not including the Type and Length fields. Oper Version (integer) Operating version of the feature. The system adjusts to operate at the highest version supported by both link partners. Max Version (integer 0-255) Highest feature version supported by the system. Enable (Boolean) Locally administered parameter that indicates whether the DCB feature is enabled. Willing (Boolean) Locally administered parameter that indicates whether this feature accepts its configuration from the peer. Error (Boolean) Indicates that an error has occurred during the configuration exchange with the peer. Subtype (integer) For Logical Link: 0 = FCoE, 1 = LAN. For negative testing or other purposes, use any value. Default = 0.
Intel 1.0 or IEEE 1.01 Custom configuration
IEEE 1.01 Priority Group configuration
Priority User priority. Priority Group ID PG to which the priority belongs. Priority Group Queue bandwidth group. PG% Percentage of link bandwidth. TCs supported Number of Traffic Classes supported by device.
IEEE 1.01 PFC configuration IEEE 1.01 FCoE configuration
User Priority Map Select a priority for this TLV. TCs supported Number of Traffic Classes that can simultaneously support PFC. User Priority Map Select a priority that is associated with FCoE traffic for this TLV. Application Protocol Id Protocol supported by DCB node: FCoE (0x8906), FIP (0x8914), Other (any 2-byte Hex number).
Pass Criteria
28-20

Performance Test - Pass Criteria Description If you check this box, IxAutomate applies the Pass Criteria to each trial in the test and determines whether the trial passed or failed. Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second (Kb/s), megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the load rate over all ports, then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest load rate experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate you entered. Fail: The DUT transmitted or received frames at a rate lower than the rate you entered.
Pass Criteria
Load Rate
% Frame Loss
Percentage of transmitted frames that were lost by the DUT. You can select either of these two methods to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest amount of frame loss experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The percentage of frames lost by the DUT was less than or equal to the number you entered. Fail: The percentage of frames lost by the DUT exceeded the number you entered.
Latency
Amount of time required by the DUT to forward frames. To specify the units of time, select nanoseconds (ns), microseconds (us), or milliseconds (ms) from the dropdown list. You can select either of these two methods to calculate the latency: Average/Port: The test averages the latency over all ports, then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, then applies the criteria to determine whether a trial passed or failed. Pass: The latency was lower than or equal to the time you specified. Fail: The latency exceeded the time you specified.
28-21
28

Test Results
For the FCoE Performance test, multiple types of results are available: FCoE Results per Flow Metrics on page 28-22. FCoE Results per Group Metrics on page 28-23. FCoE Results per Port Metrics on page 28-24. Non-FCoE Results per Binary Iteration on page 28-25. Non-FCoE Results per Port Metrics on page 28-25. FCoE and Non-FCoE Aggregate Results Metrics and Aggregate Metrics on page 28-26. Pause Frame Results Metrics and Aggregate Pause Frame Results Metrics on page 28-27.
FCoE Results per Flow Metrics

For binary search iteration only, the statistics available in iterationResultsPerFlow.csv are: Tx Count (frames) Rx Count (frames) Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps) Avg Latency (ns) Min Latency (ns) Max Latency (ns) Small Seq Errors Big Seq Errors Reverse Seq Errors Total Seq Errors Integrity Errors
For linear search iteration only, the statistics available in iterationResultsPerFlow.csv are: Tx Count (frames) Rx Count (frames)
28-22

Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps) Avg Latency (ns) Min Latency (ns) Max Latency (ns) Avg Delay Variation (ns) Min Delay Variation (ns) Max Delay Variation (ns) Integrity Errors
FCoE Results per Group Metrics

For binary search iteration only, the statistics available in iterationResultsPerGroup.csv are: Tx Count (frames) Rx Count (frames) Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps) Avg Latency (ns) Min Latency (ns) Max Latency (ns) Small Seq Errors Big Seq Errors
28-23
28

Reverse Seq Errors Total Seq Errors
For linear search iteration only, the statistics available in iterationResultsPerGroup.csv are: Tx Count (frames) Rx Count (frames) Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps) Avg Latency (ns) Min Latency (ns) Max Latency (ns) Avg Delay Variation (ns) Min Delay Variation (ns) Max Delay Variation (ns)
FCoE Results per Port Metrics

For binary search iteration only, the statistics available in iterationResultsPerPort.csv are: Tx Count (frames) Rx Count (frames) Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps)
28-24

Avg Latency (ns) Min Latency (ns) Max Latency (ns) Small Seq Errors Big Seq Errors Reverse Seq Errors Total Seq Errors Integrity Errors
For linear search iteration only, the statistics available in iterationResultsPerPort.csv are: Tx Count (frames) Rx Count (frames) Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps) Avg Latency (ns) Min Latency (ns) Max Latency (ns) Avg Delay Min Delay Variation (ns) Max Delay Variation (ns) Integrity Errors
Non-FCoE Results per Binary Iteration

For binary search iterations, iteration.csv contains non-FCoE traffic results.
Non-FCoE Results per Port Metrics

The statistics available in the Non FCoE Results Per Port Metrics are:
28-25
28

Tx Count (frames) Rx Count (frames) Frame Loss (frames) Frame Loss (% Line rate) Tx Tput (fps) Tx Tput (% Line Rate) Tx Tput (kbps) Rx Tput (fps) Rx Tput (% Line Rate) Rx Tput (kbps) Avg Latency (ns) Min Latency (ns) Max Latency (ns) Small Seq Errors Big Seq Errors Reverse Seq Errors Total Seq Errors Integrity Errors
FCoE and Non-FCoE Aggregate Results Metrics and Aggregate Metrics

The statistics available in the FCoE Aggregate Results Metrics and non-FCoE Aggregate Results Metrics (when the non-FCoE traffic is enabled), or Aggregate Results Metrics (when the non-FCoE traffic is disabled) are: Total Tx Count (frames) Total Rx Count (frames) Total Frame Loss (frames) Total Frame Loss (% Line rate) Agg TxTput (fps) Agg Tx Tput (% Line Rate) Agg Tx Tput (kbps) Agg Rx Tput (fps) Agg Rx Tput (% Line Rate) Agg Rx Tput (kbps)
If Calculate Jitter is disabled:
28-26

Total Small Seq Errors Total Big Seq Errors Total Reverse Seq Errors Agg Total Seq Errors Agg Data Errors
If Calculate Jitter is enabled: Min Delay Variation (ns) Max Delay Variation (ns) Avg Delay Variation (ns)
Pause Frame Results Metrics and Aggregate Pause Frame Results Metrics
The statistics available in pauseFramesResults.csv for linear search, with IEEE 802.1Qbb flow control type are: Trial Unicast Frame Size Frame Size Iteration Tx Port Priority Group Pause Frames
The statistics available in pauseFramesResults.csv for binary search, with IEEE 802.1Qbb flow control type are: Trial Unicast Frame Size Frame Size Tx Port Priority Group Pause Frames
The statistics available in pauseFramesResults.csv for linear search, with IEEE 802.3x flow control type are: Trial Unicast Frame Size Frame Size Tx Port
28-27
28

Pause End Frames Pause OverWrite Frames Pause Ack Frames
The statistics available in pauseFramesResults.csv for binary search, with IEEE 802.3x flow control type are: Trial Frame Size Tx Port Pause End Frames Pause OverWrite Frames Pause Ack Frames
The statistics available in AggregatePauseFramesResult.csv for linear search, with IEEE 802.1Qbb flow control type are: Trial Unicast Frame Size Iteration Priority Group Total Pause Frames
The statistics available in AggregatePauseFramesResult.csv for binary search, with IEEE 802.1Qbb flow control type are: Trial Unicast Frame Size Frame Size Priority Group Total Pause Frames
The statistics available in AggregatePauseFramesResult.csv for linear search, with IEEE 802.3x flow control type are: Trial Unicast Frame Size Frame Size Total Pause End Frames Total Pause OverWrite Frames Total Pause Ack Frames
The statistics available in AggregatePauseFramesResult.csv for binary search, with IEEE 802.3x flow control type are:
28-28

Trial Frame Size Total Pause End Frames Total Pause OverWrite Frames Total Pause Ack Frames

This test performs RFC 2544 throughput testing of mixed class traffic, FCoE and non-FCoE traffic. The non-FCoE traffic consists of multicast and unicast traffic. For a diagram of traffic flow, refer to Figure 28-3 on page 28-29.
Ixia Tx Ports
FCoE Mixed Class Throughput
Ixia Rx Ports
DUT
Ethernet Multicast traffic FCoE traffic Ethernet Unicast traffic
Figure 28-3. FCoE Mixed Class Throughput Test: Traffic Flow Diagram
This section covers the following topics: Test Cycle on page 28-30. Traffic Setup Parameters on page 28-30. Supported Protocols on page 28-33. Run Parameters on page 28-33. FCoE Advanced Parameters on page 28-34. LLDP/DCBX Parameters on page 28-34. Pass Criteria on page 28-34.
28-29
28

Test Results on page 28-34.
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, configuring all ports and setting up port speeds, modes, and addresses. If you choose to simulate FCoE and/or non-FCoE interfaces on the ports, the interfaces are configured. For Ethernet Unicast traffic, if the IP protocol is set, the ARP requests are sent; if the MAC protocol is set, the MAC learning frames are sent. For the FCoE traffic, the discovery requests are sent. For the Ethernet Multicast traffic, if the IP protocol is set, the ARP requests are sent; if the IPv6 protocol is set, the Neighbor Discovery frames are sent. However the ARP/ND are performed for the multicast ports only when "Enable send ARP/Neighbor Discovery" is selected under Learning Frames. For the Ethernet Multicast traffic the join frames will be sent for multicast ports for the configured group addresses. Once the transmit/receive ports and the simulated interfaces are configured, the test starts the first iteration. After the streams are configured, the traffic is transmitted for the specified period of time. When finishing the frames transmission, the test allows two seconds for any additional frames to come in. When the additional time expires, the test starts collecting statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports. The binary or linear search algorithm can be used to calculate the DUT throughput. Additionally, the latency can be calculated for the test. For FCoE traffic, the test performs the linear or binary search using the first frame size; if you specified more than one frame size, the test restarts the search using the next one. If the Ethernet Unicast traffic is enabled, it uses the same frame size for all iterations. If you specified more than one trial, the test restarts, using the first frame size. If Ethernet Multicast traffic is enabled, it uses the same frame size for all iterations. If you specified more than one trial, the test restarts, using the first frame size. For each iteration, the test calculates the DUT throughput, latency, and frame loss percentage. The test continues until all trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost frames. After gathering statistics, it prints the results.

28-30
In Traffic Setup there are three tabs:

Ethernet Unicast Traffic Parameters on page 28-31. FCoE Traffic Parameters on page 28-31. Ethernet Multicast Traffic Parameters on page 28-31.
Ethernet Unicast Traffic Parameters

Table 28-9 describes the parameters from the Ethernet Unicast Traffic Parameters tab that are unique for this test.
Table 28-9. Parameter PFC Group Increment By VLAN User Priority Increment By Performance Test Ethernet Unicast Traffic Parameters Description Description Specify the priority group number. It can be mapped to the priority field in the frame. Increments PFC Group between ports. The user priority of the VLAN tag (values 0 through 7). Increments VLAN user priority between ports.
FCoE Traffic Parameters

The FCoE Traffic Parameters tab contains the same configuration regions as in the FCoE Performance test (FCoE Parameters on page 28-4).
Ethernet Multicast Traffic Parameters

Figure 28-4 shows the Ethernet Multicast Traffic Parameters dialog box.
28-31
28

Figure 28-4.Mixed Class Throughput Test - Ethernet Multicast Traffic Parameters
The Multicast Traffic Parameters dialog box provides the means for you to configure the following: Enable Multicast Traffic: Select to enable multicast traffic.
Frame Size: Specify the size of the frames to transmit. For more information about frame sizes, refer to Choosing Frame Sizes on page 3-45. Learning Frames: Frame Data: 18. Refer to Configuring Learning Frames on page 3-23.
Refer to Configuring IP, IPX, and MAC Addresses on page 3-
Traffic Map: The traffic setup section allows you to configure the traffic maps. You can configure the mapping at the interface level, but not at the port level. You can assign multiple interfaces to each port. For more information, refer to Traffic Map Parameters on page 28-5.
28-32

Multicast Parameters: 28-10).
Specify the parameters for multicast data (Table
Table 28-10. Mixed Class Throughput Test - Multicast Parameters Parameter First Group Address IGMP Version Total Group Addresses Description IP address of the first multicast group. The IGMP version to use: 1, 2, or 3. The number of group addresses to be assigned to each port. During the test, each port joins this number of groups starting with the group specified by First Group Address. How addresses are allocated among ports: Accumulated The same addresses are duplicated on each port. Distributed The addresses are divided among the ports. Join/Leave Rate (fps) Enable Leave Group The number of frames per second sent for Join/Leave messages. If selected, the hosts simulated by the Ixia port send IGMP Leave Group messages to the DUT at the end of the test. If selected, the IP header Send Router Alert bit is set in messages.
Group Type
Enable Router Alert
Supported Protocols

Supported Protocols Features Required on Ports Transmit port IP, IPv6 Advanced Scheduler mode Receive port Wide Packet Group mode
Run Parameters
Refer to Run Parameters on page 28-11.

NOTE: Traffic Type Ratios are percentages of FCoE, Unicast, and Multicast frames within the traffic stream. The sum of the mixed traffic is always 100. Max Rate determines the speed at which the test transmits and the test applies the values for FCoE, Unicast, and Multicast to the Max rate value. The ratios apply only for ports sending mixed traffic; the other ports send only one type of traffic at the Max Rate value. For the ports sending two types of traffic, the third ratio is split between the two types of traffic based on the ratio for each.
28-33
28

PFC Throughput Test
FCoE Advanced Parameters LLDP/DCBX Parameters Pass Criteria Test Results
Refer to FCoE Advanced Parameters on page 28-14.
Refer to LLDP/DCBX Parameters on page 28-17.
Refer to Pass Criteria on page 28-20. Refer to Test Results on page 28-22.
PFC Throughput Test

This test is similar to the FCoE Performance Test on page 28-2 except for the following: In addition, the binary search algorithm uses pause frames to determine pass/ fail criteria. Flow control is always enabled.
Figure 28-5 shows the traffic flow diagram for this test .
Ixia Tx Ports
FCoE PFC Throughput
Ixia Rx Ports
DUT
FCoE traffic
Non-FCoE traffic
Figure 28-5. FCoE PFC Throughput Test: Traffic Flow Diagram
This section covers the following topics: Test Cycle on page 28-35.
28-34

PFC Throughput Test
Traffic Setup Parameters on page 28-36. Supported Protocols on page 28-36. Run Parameters on page 28-36. FCoE Advanced Parameters on page 28-36. LLDP/DCBX Parameters on page 28-36. Pass Criteria on page 28-36. Test Results on page 28-36.
Test Cycle
The test starts by connecting to the chassis, creating the port mappings for the test, configuring all ports and setting up port speeds, modes, and addresses. If you choose to simulate FCoE and/or non-FCoE interfaces on the ports, the interfaces are configured. For the Ethernet Unicast traffic, if the IP protocol is set, the ARP requests are sent; if the MAC protocol is set, the MAC learning frames are sent. For the FCoE traffic, the discovery requests are sent. Once the transmit/receive ports and the simulated interfaces are configured, the test starts the first iteration. After the streams are configured, the traffic is transmitted for the specified period of time. When finishing the frames transmission, the test allows two seconds for any additional frames to come in. When the additional time expires, the test starts collecting statistics on how many of the transmitted frames were forwarded by the DUT to the receive ports. The binary/linear search algorithm is used to calculate the DUT throughput. If binary search is selected, the algorithm also uses the pause frames to determine whether a particular iteration is passed/failed. If any pause frame is received on the FCoE traffic queue, the iteration is considered failed and is restarted with a reduced FCoE traffic rate as per the binary algorithm. However the Ethernet traffic rate will remain with the fixed rate configured. Pause frames in the Ethernet traffic queue are neglected. For FCoE traffic, the test performs the search using the first frame size; if you specified more than one frame size, the test restarts the search using the next one. If Ethernet unicast traffic is enabled, an inner-outer loop of iterations based on the frame sizes selected for Ethernet and FCoE are performed. Ethernet frame sizes will form the outer loop while FCoE frame sizes perform the inner loop of iterations. If you specified more than one trial, the test restarts, using the first Ethernet frame size. For each iteration, the test calculates the DUT throughput, latency, and frame loss percentage.
28-35
28

PFC Throughput Test
The test continues until all trials and frame sizes complete. It then gathers statistics on the number of transmitted and lost frames. After gathering statistics, it prints the results.
Traffic Setup Parameters Supported Protocols
Traffic setup is the same as in the FCoE Performance Test (Traffic Setup Parameters on page 28-3). The protocols supported by this test are:
Supported Protocols Features Required on Ports Transmit port IP, IPv6 Advanced Scheduler mode Receive port Wide Packet Group mode
Run Parameters FCoE Advanced Parameters LLDP/DCBX Parameters Pass Criteria Test Results
Run Parameters are the same as in the FCoE Performance Test (Run Parameters on page 28-11) except Enable Flow Control is always selected and is grayed out. FCoE Advanced Parameters are the same as in the FCoE Performance Test (FCoE Advanced Parameters on page 28-14) except that jitter is not calculated. Refer to LLDP/DCBX Parameters on page 28-17.
Refer to Pass Criteria on page 28-20. All test results are the same as those generated by the FCoE Performance Test (Test Results on page 28-22) except that jitter statistics are not calculated.
28-36
29
Chapter 29:
Metro Performance Test Suite

Data Plane Test on page 29-1. QoS Test on page 29-19.
The Metro Performance test suite consists of:
Data Plane Test

The test determines the DUT layer 2 forwarding performances while receiving and transmitting VLAN tagged, VLAN stacked, MAC-in-MAC, or T-MPLS traffic unidirectionally or bi-directionally. It provides a report of the maximum DUT throughput using either a binary or a linear search while also specifying loss, latency, sequence error and data integrity statistics. Figure 29-1 illustrates data flow in the Data Plane test.
Figure 29-1. Data Plane Traffic Flow Diagram
This section covers the following Data Plane test topics:
29-1
29

Data Plane Test
Traffic Setup on page 29-2. Test Setup on page 29-7. Results on page 29-17.
Traffic Setup
The traffic setup involves the following configuration regions: Frame Size on page 29-2. Learning Frames on page 29-3. Frame Data on page 29-4. Traffic Map on page 29-5.
Frame Size
Figure 29-2 illustrates the Frame Size dialog box.
Figure 29-2. Frame Size
Frame Size: 64 frame size will be disabled. Table 29-1 lists the minimum frame size supported. Mandatory fields are marked in red.
Minimum Frame Size Supported
Sequence Errors TMPLS Header Min FS with all options Data Integrity
Table 29-1.
Client Header/ Ethernet Type C-Tag Header S-Tag Header MinM Header
Signature
Latency
VLAN Q-in-Q
14 14
4 4
0 4
0 0
0 0
4 4
14 14
4 4
6 6
2 2
4 4
64 64
Min FS
PGID
CRC
64 64
*Either C-Tag or S-Tag can be enabled in the MAC-in-MAC or T-MPLS frames. Both C-Tag and S-Tag ar not mandatory, e but one or the other is.
29-2

Data Plane Test
Table 29-1.
Minimum Frame Size Supported (Continued)

Signature
Latency
MAC-inMAC T-MPLS
14 14
4* 4*
4* 4*
22 0
0 22
4 4
14 14
4 4
6 6
2 2
4 4
64 64
Min FS
PGID
CRC
78 78
Although the test supports running with lower frame sizes, the minimum valid frame size for each of the protocols is as follows: 802.1Q MAC frame should be 68 bytes 802.1ad PB/Q-in-Q frame should be 72 bytes. 802.1ah PBB/MAC-in-MAC frame should be: 90 bytes, assuming only C-TAG exists 90 bytes, assuming only S-TAG exists 94 bytes, assuming both S-TAG and C-TAG exists
T-MPLS should be: 90 bytes, assuming only C-TAG exists 90 bytes, assuming only S-TAG exists 94 bytes, assuming both S-TAG and C-TAG exists
Learning Frames
Figure 29-3 illustrates the Learning Frames dialog box.
29-3
29

Data Plane Test
Figure 29-3. Learning Frames
The Learning Frames contents remains same for all the tests (Q-in-Q, MAC-inMAC). The learning frames will be sent as L2 traffic from all rx ports, for the DUT to learn the MAC addresses.
Frame Data
Figure 29-4 illustrates the Frame Data dialog box.
Figure 29-4. Frame Data
The Frame Data Protocol supported will be MAC only. The VLAN configuration parameters are available under Test Setup > Client and Q-in-Q Parameters and Carrier Network Parameters tabs.
29-4

Data Plane Test
Traffic Map
Figure 29-5 illustrates the Traffic Map dialog box.
Figure 29-5. Traffic Map
Both manual and automatic traffic mapping is supported. The traffic can be unidirectional and bi-directional. A one to one mapping is supported. Traffic Flow - specifies the type of the packet on the transmit side and the type of the packet at the receive side. The TX and RX are selected depending on the type of DUT. Following is a table with the supported of TX and RX combinations and the type of DUT in each case. Figure 29-6 lists the traffic flow parameters available at Tx and Rx.
Figure 29-6. Traffic Flow Parameters
Tx - Frame type on transmission side. Default: VLAN. Table 29-2 lists the possible traffic flow combinations. Rx - Frame type at the receive side. Default: Q-in-Q. Table 29-2 lists the possible traffic flow combinations.
29-5
29

Data Plane Test
Table 29-2. Tx VLAN VLAN VLAN VLAN Q-in-Q Q-in-Q Q-in-Q Q-in-Q MAC-inMAC MAC-inMAC MAC-inMAC MAC-inMAC T-MPLS T-MPLS T-MPLS T-MPLS
Traffic Flow Combinations Rx VLAN Q-in-Q MAC-in-MAC T-MPLS VLAN Q-in-Q MAC-in-MAC T-MPLS VLAN Q-in-Q MAC-in-MAC T-MPLS VLAN Q-in-Q MAC-in-MAC T-MPLS DUT L2 Switch Ingress Provider Edge Bridge Ingress Provider Backbone Edge Bridge Ingress Carrier Edge Bridge Egress Provider Edge Bridge Provider Core Bridge Ingress Provider Backbone Edge Bridge Ingress Carrier Edge Bridge Egress Provider Backbone Edge Bridge Egress Provider Backbone Edge Bridge Provider Backbone Core Bridge N/A Egress Carrier Edge T-MPLS Switch Egress Carrier Edge T-MPLS Switch N/A Carrier Core T-MPLS Switch
Figure 29-7 illustrates the Manual Port Map - One To One dialog box.
29-6

Data Plane Test
Figure 29-7. Manual Port Map - One To One
NOTE: For Manual mode the port should be mapped in one direction; and for the other direction the Direction parameter should be used. If a port is mapped from Manual Configuration window as both tx and rx port the test will fail with an error message.
Test Setup
The Test Setup tab contains the following tabs: Run Parameters on page 29-7. Client and Q-in-Q Parameters on page 29-10. Carrier Network Parameters on page 29-13.
Run Parameters
Figure 29-8 illustrates the Run Parameters dialog box.
29-7
29

Data Plane Test
Figure 29-8. Run Parameters
Duration - the transmit duration per iteration. Test Parameters: No. of trials - number of trials to be executed in the test Calculate Latency - if checked the latency measurements will be done. Calibrate Latency - if checked the latency calibration will be performed; enabled only if Calculate Latency is checked. Latency Type - specify the method for calculating latency (Cut Through/ Store and Forward); enabled only if Calculate Latency is checked. Staggered Transmit - if checked a 25-30 ms delay is introduced between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, this parameters should be used if the DUT cannot cope with test traffic arriving on all ports at the same time. Sequence Errors - if checked sequence checking measurements are performed and the values reported in the test output Data Integrity - if checked data integrity checking measurements are performed and the values reported in the test output
Iteration - contains the parameter that defines the iteration loop control: Binary radio button - if selected a binary search algorithm is performed to search the throughput rate at which the frame loss is in the tolerance specified and the difference between 2 consecutive iterations is bigger then the resolution.
29-8

Data Plane Test
Linear radio button - if selected a linear iteration is performed based on the initial rate value, the number of iterations and the increment step specified. No. of iterations - number of linear iterations to be performed when linear iteration is used; enabled only when Linear radio button is selected. Loss Tolerance (%) - the acceptable tolerance for the lost frames when searching the throughput rate; enabled only when Binary radio button is selected. Resolution - the minimum difference between 2 binary search iterations. If the difference is going below the resolution value the binary search algorithm is stopped even if the throughput rate wasn't reached; enabled only when Binary radio button is selected. Init Rate - the initial rate from where the binary search algorithm starts (when Binary radio button is selected) or the used rate for the first linear iteration (when the Linear radio button is selected); the value can be specified in %, fps or kbps (bit rate; without including preamble) depending on the right combo box selection. Increment - the increment step to be used between linear iterations; enabled only when Linear radio button is selected.
Pass Criteria - contains the criteria to be applied per each trial and determine if the trials passed or failed. If multiple criteria are applied the results of all criteria are aggregated in one, and if at least one failed the trial is considered to be failed. Load Rate - Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). Either of the following two methods can be selected to calculate the percentage of lost frames: Average/Port: The test averages the frame loss over all ports, and then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, and then applies the criteria to determine whether a trial passed or failed.
Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate entered. Fail: The DUT transmitted or received frames at a rate lower than the rate entered. Latency - the amount of time required by the DUT to forward frames. In order to specify the time units, nanoseconds (ns), microseconds (us), or milliseconds (ms) can be selected from the drop-down list. Either of the following two methods can be selected to calculate the latency: Average/Port: The test averages the latency over all ports, and then applies the criteria to determine whether a trial passed or failed.
29-9
29

Data Plane Test
Maximum Port: The test selects the longest latency experienced on each port, and then applies the criteria to determine whether a trial passed or failed.
Pass: The latency was less than or equal to the time specified. Fail: The latency exceeded the time specified. Total Sequence Errors - the number of frames received with sequence errors. Either of the following two methods can be selected to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, and then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with sequence errors on each port, and then it applies the criteria to determine whether a trial passed or failed.
Pass: The number of frames received with sequence errors was equal to or lower than the number entered. Fail: The number of frames received with sequence errors was greater than the number entered. Total Data Integrity Errors - the number of frames received with CRC errors. Either of the following two methods can be selected to calculate the CRC errors: Average/Port: The test averages the frames received with CRC errors over all ports, and then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with CRC errors on each port, and then it applies the criteria to determine whether a trial passed or failed.
Pass: The number of frames received with CRC errors was less than or equal to the number entered. Fail: The number of frames received with CRC errors was greater than the number entered
Client and Q-in-Q Parameters

Figure 29-9 illustrates the Client and Q-in-Q Parameters dialog box.
29-10

Data Plane Test
Figure 29-9. Client and Q-in-Q Parameters
Client Parameters: C-Tag - this parameter is available only for MAC-in-MAC and T-MPLS traffic types to select if C-Tag should be included in the frame. This parameter won't be used for VLAN and Q-in-Q traffic. First C-Vlan ID - the id of C-Tag of the first Customer Equipment (CE). Default: 100. No. of C-tags- the number of C-Tags on a physical port. Represents the number of emulated CEs on a physical port. Default: 1. Increment by - the increment step for Vlan ID between the emulated CEs on a port, and between the CEs emulated on different ports. Default: 1 No. of MAC Addresses- the number of addresses emulated per each CE. Default: 1 C-Tag Ethernet Type - the Ethernet Type that is set in the C-Tag frame. Available values: 0x8100, 0x88a8, and user defined. Default: 0x8100 Source MAC Address: First Address - the MAC address of the first address of the first CE emulated on the first tx port. Default: 00 CE EF DB 00 01 Increment by - the increment specified in MAC format between the addresses on the same CE on a tx port, between the addresses on CEs on the same tx port and between the addresses on the CEs on the emulated on all tx ports. Default: 00 00 00 00 00 01
29-11
29

Data Plane Test
Unicast Destination MAC Address: First Address - the unicast MAC address of the first address of the first CE emulated on the first rx port. Default: 00 CE EF DC 00 01 Increment by - the increment specified in MAC format between the addresses on the same CE on a rx port, between the addresses on CEs on the same rx port and between the addresses on the CEs on the emulated on all rx ports. Default: 00 00 00 00 00 01
Multicast Destination MAC Address: First Address - the multicast MAC address of the first address of the first CE emulated on the first rx port. Default: 01 00 5E 00 00 00 Increment by - the increment specified in MAC format between the addresses on the same CE on a rx port, between the addresses on CE on the same rx port and between the addresses on the CEs on the emulated on all rx ports. Default: 00 00 00 00 00 00
Q-in-Q Parameters: S-Tag - this parameter is available only for MAC-in-MAC and T-MPLS traffic types to select if S-Tag should be included in the frame. This parameter won't be used for Q-in-Q traffic. First S-Vlan ID - the id of the S-Tag of the first emulated Provider Edge (PE). Default: 1000. No. of S-Tags - the number of S-Tags on a physical port. Represents the number of emulated PEs on a physical port. Default: 1. Increment by - the increment step for Vlan ID between the emulated PEs on a port, and between the PEs emulated on different ports. Default: 1. S-Tag Ethernet Type - the Ethernet Type that is set in the S-Tag frame. Available values: 0x8100, 0x88a8, and user defined. Default: 0x8100
Traffic Mix Percentage (%): This is the ratio of each type of traffic transmitted to the Load Rate value specified under Iteration parameters. Unicast - the percentage of the traffic transmitted that is unicast. Default: 100 Broadcast - the percentage of the traffic transmitted that is broadcast. Default: 0 Multicast - the percentage of the traffic transmitted that is multicast. Default: 0
NOTE: The mapping between the C-Tags and S-Tags per port it will be done by distributing the C-Tags in order to each S-Tag in order (for example, refer to Table 29-3).
Example (refer to Table 29-3 for C- and S-Tag mapping): First C-Vlan ID: 200 No. of C-Tags per port: 5
29-12

Data Plane Test
Increment C-Tag Vlan: 1 First S-Vlan ID: 1000 No. of S-Tags per port: 2 Increment S-Tag Vlan: 1
Table 29-3. C-Tag 200 201 202 203 204 C- and S-Tag Mapping Example S-Tag 1000 1001 1000 1001 1000
Traffic Mix - the frame contains the ratios for each type of traffic transmitted. The percentage value represents the ratio from the Load Rate value specified under Iteration parameters. Unicast - the percentage of the unicast traffic from the entire traffic that will be transmitted. Default: 100. Multicast - the percentage of the unicast traffic from the entire traffic that will be transmitted. Default: 0. Broadcast - the percentage of the unicast traffic from the entire traffic that will be transmitted. Default: 0.
Carrier Network Parameters

Figure 29-10 illustrates the Carrier Network Parameters dialog box.
29-13
29

Data Plane Test
Figure 29-10.Carrier Network Parameters
MAC-in-MAC Parameters: First B-Vlan ID - the id of B-Tag of the first Provider Backbone Bridge. Default: 2000. No. of B-Tags per port - the number of B-Tags on a physical port. Represents the number of emulated Provider Backbone Bridges on a physical port. Default: 1. Increment B-Tag Vlan - the increment step for Vlan ID between the emulated Provider Backbone Bridges on a port and between the Provider Backbone Bridges emulated on different ports. Default: 1 First I-SID - the ID of the I-Tag associated with the first C-Tag/S-Tag pair. If C-Tag is not enabled in the stream, this is the ID of the I-Tag associated with the first S-Tag. If S-tag is not enabled in the stream, this is the ID of the I-Tag associated with the first C-Tag. Default: 10. Increment I-SID - the increment step for I-SID between the B-Tags. Default: 1 Backbone SA MAC Address: First Address - the MAC address of the first address of the first Provider Backbone Bridges emulated on the first tx port. Default: 00 DE EF DB 00 01 Increment by - the increment specified in MAC format between the addresses of Provider Backbone Bridges emulated on the same tx port and between the addresses on the Provider Backbone Bridges emulated on different tx ports. Default: 00 00 00 00 00 01
29-14

Data Plane Test
NOTE: Currently the test supports only one Provider Backbone Bridge emulated per each port.
Backbone DA MAC Address: First Address - the MAC address of the first address of the first Provider Backbone Bridges emulated on the first rx port. Default: 00 DE EF DC 00 01 Increment by - the increment specified in MAC format between the addresses on Provider Backbone Bridges emulated on the same rx port and between the addresses on the Provider Backbone Bridges emulated on different rx ports. Default: 00 00 00 00 00 00.
NOTE: Currently the test supports only one Provider Backbone Bridge emulated per each port.
NOTE: The mapping between the C-Tags, S-Tags, B-Tags, and I-Tags per port is done by distributing the S-Tag/C-Tag pairs s in order to each B-Tag in order following the number of S-Tags and by distributing the S-Tags/C-Tag pairs in order to each I-Tag in order following the number of C-Tags (for example, refer to Table 29-4).
Example (refer to Table 29-4 for C-Tag, S-Tag, B-Tag, and I-Tag mapping): First C-Vlan ID: 200 No. of C-Tags per port: 8 Increment C-Tag Vlan: 1 First S-Vlan ID: 1000 No. of S-Tags per port: 5 Increment S-Tag Vlan: 1 First B-Vlan ID: 2000 No. of B-Tags per port: 2 Increment B-Tag Vlan: 1 First I-SID: 10 Increment I-SID: 1
Table 29-4. C-Tag 200 201 202 203 204 205 C-, S-, B- and I-SID Mapping Example S-Tag 1000 1001 1002 1003 1004 1000 B-Tag 2000 2001 2000 2001 2000 2000 I-SID 10 11 12 13 14 15
29-15
29

Data Plane Test
Table 29-4. C-Tag 206 207
C-, S-, B- and I-SID Mapping Example (Continued) S-Tag 1001 1002 B-Tag 2001 2000 I-SID 16 17
NOTE: The I-TAG Ethertype will not be configurable and it will be set to the standard 0x88E7. T-MPLS Parameters: First TMP Label ID - the first TMP label id of the first T-MPLS switch. Default: 16. Increment By - the increment step for TMP label ids between the emulated T-MPLS switches on a port and between the T-MPLS switches emulated on different ports. Default: 1 First TMC Label ID - the first TMC label id of the first T-MPLS switch. Default: 16. Increment By - the increment step for TMP label ids between the emulated T-MPLS switches on a port and between the T-MPLS switches emulated on different ports. Default: 1 No. of Labels - the number of labels on a physical port. Represents the number of emulated T-MPLS switch on a physical port. Default: 1. T-MPLS SA MAC Address: First Address - the MAC address of the first address of the first TMPLS switch emulated on the first tx port. Default: 00 FE EF DB 00 01 Increment by - the increment specified in MAC format between the addresses on T-MPLS switches emulated on the same tx port and between the addresses on the T-MPLS switches emulated on different tx ports. Default: 00 00 00 00 00 01
NOTE: Currently the test supports only one T-MPLS switch emulated per each port.
T-MPLS DA MAC Address: First Address - the MAC address of the first address of the first TMPLS switch emulated on the first rx port. Default: 00 FE EF DC 00 01 Increment by - the increment specified in MAC format between the addresses on T-MPLS switches emulated on the same rx port and between the addresses on the T-MPLS switches emulated on different rx ports. Default: 00 00 00 00 00 00
29-16

Data Plane Test
NOTE: The mapping between the C-Tags, S-Tags, and T-MPLS Labels per port is done by distributing the S-Tag/C-Tag pairs in order to each TMP/TMC label pair in order following the number of S-Tags (for example, refer to Table 29-5).
Example (refer to Table 29-5 for C-Tag, S-Tag, and T-MPLS label mapping): First C-VLAN ID: 200 No. of C-Tags per port: 8 Increment C-Tag VLAN: 1 First S-Vlan ID: 1000 No. of S-Tags per port: 5 Increment S-Tag VLAN: 1 First TMP Label ID: 1 Increment TMP Label: 1 First TMC Label ID: 10000 Increment TMC Label: 1 No. of labels per port: 2
Table 29-5. C-Tag 200 201 202 203 204 205 206 207 C-Tag, S-Tag, and T-MPLS Label Mapping Example S-Tag 1000 1001 1002 1003 1004 1000 1001 1002 TMP Label 16 17 16 17 16 16 17 16 TMC Label 10000 10001 10000 10001 10000 10000 10001 10000
Results
The test results are reported as follows: Results on page 29-17. Aggregate Results on page 29-18. Iteration on page 29-19.
Results
Results.csv contains the following information:
Trial
29-17
29

Data Plane Test
Frame size Iteration (only when linear search is selected) Tx Port Rx Port C-Tag/S-Tag VLAN IDs B-Tag VLAN ID/I-SID (only for MAC-in-MAC) MPLS Labels (only for T-MPLS) Throughput Frame Rate Tx Rate (Mbps) Tx Count Rx Count Frame Loss Frame Loss % Latency (Min Latency, Avg Latency, Max Latency) Sequence Errors (Small Seq Errors, Big Seq Errors, Revert Seq Errors, Total Seq Errors) Data Integrity Errors
Aggregate Results
AggregateResults.csv contains the following information:
Trial Frame size Iteration (only when linear search is selected) Throughput Frame Rate Tx Rate (Mbps) Tx Count Rx Count Frame Loss Frame Loss % Latency (Min Latency, Avg Latency, Max Latency) Sequence Errors (Small Seq Errors, Big Seq Errors, Revert Seq Errors, Total Seq Errors) Data Integrity Errors
29-18

QoS Test
Iteration
When binary search is selected Iteration.csv contains the following information: Trial Frame size Iteration Tx Port Rx Port C-Tag/S-Tag VLAN IDs B-Tag VLAN ID/I-SID (only for MAC-in-MAC) MPLS Labels (only for T-MPLS) Throughput Frame Rate Tx Rate (Mbps) Tx Count Rx Count Frame Loss Frame Loss % Latency (Min Latency, Avg Latency, Max Latency) Sequence Errors (Small Seq Errors, Big Seq Errors, Revert Seq Errors, Total Seq Errors) Data Integrity Errors
QoS Test
The test determines the DUT layer 2 forwarding performances while receiving VLAN tagged, VLAN stacked, MAC-in-MAC or T-MPLS traffic unidirectionally in one-to-one or many-to-one traffic pattern with QoS enabled. It uses the VLAN Priority field and T-MPLS EXP field to verify QoS enforcement. It provides a report of the maximum DUT throughput using either a binary or a linear search while also specifying loss, latency, sequence error and data integrity statistics. Figure 29-11 illustrates data flow in the QoS test.
29-19
29

QoS Test
Figure 29-11. QoS Traffic Flow Diagram
This section covers the following QoS test topics: Traffic Setup on page 29-20. Test Setup on page 29-25. Results on page 29-37.
Traffic Setup
The traffic setup involves the following configuration regions: Frame Size on page 29-20. Learning Frames on page 29-22. Frame Data on page 29-22. Traffic Map on page 29-23.
Frame Size
Figure 29-6 illustrates the Frame Size dialog box.
29-20

QoS Test
Table 29-6.
Frame Size
Frame Size: 64 frame size will be disabled. Table 29-7 lists the minimum frame size supported. Mandatory fields are marked in red.
Minimum Frame Size Supported
Table 29-7.
Signature
Latency
VLAN Q-in-Q MAC-inMAC T-MPLS
14 14 14 14
4 4 4* 4*
0 4 4* 4*
0 0 22 0
0 0 0 22
4 4 4 4
14 14 14 14
4 4 4 4
6 6 6 6
2 2 2 2
4 4 4 4
64 64 64 64
Min FS
PGID
CRC
64 64 78 78
Although the test supports running with lower frame sizes, the minimum valid frame size for each of the protocols is as follows: 802.1Q MAC frame should be 68 bytes 802.1ad PB/Q-in-Q frame should be 72 bytes. 802.1ah PBB/MAC-in-MAC frame should be: 90 bytes, assuming only C-TAG exists 90 bytes, assuming only S-TAG exists 94 bytes, assuming both S-TAG and C-TAG exists
T-MPLS should be: 90 bytes, assuming only C-TAG exists
29-21
29

QoS Test
90 bytes, assuming only S-TAG exists 94 bytes, assuming both S-TAG and C-TAG exists
Learning Frames
Figure 29-12 illustrates the Learning Frames dialog box.
Figure 29-12.Learning Frames
The Learning Frames contents remains same for all the tests (Q-in-Q, MAC-inMAC). The learning frames will be sent as L2 traffic from all rx ports, for the DUT to learn the MAC addresses.
NOTE: The learning is not performed for T-MPLS case.
Frame Data
Figure 29-13 illustrates the Frame Data dialog box.
29-22

QoS Test
Figure 29-13.Frame Data
The Frame Data Protocol supported will be MAC only. The VLAN configuration parameters are available under Test Setup > Client and Q-in-Q Parameters and Carrier Network Parameters tabs.
Traffic Map
Figure 29-14 illustrates the Traffic Map dialog box.
Figure 29-14.Traffic Map
Both manual and automatic traffic mapping is supported. The traffic is unidirectional only. A many to one mapping is supported. Traffic Flow - specifies the type of the packet on the transmit side and the type of the packet at the receive side. The TX and RX are selected depending
29-23
29

QoS Test
on the type of DUT. Following is a table with the supported of TX and RX combinations and the type of DUT in each case. Figure 29-15 lists the traffic flow parameters available at Tx and Rx.
Figure 29-15.Traffic Flow Parameters
TX - Frame type on transmission side. Default: VLAN. Table 29-8 lists the valid traffic flow combinations. RX - Frame type at the receive side. Default: Q-in-Q. Table 29-8 lists the valid traffic flow combinations.
Traffic Flow Combinations Rx VLAN Q-in-Q MAC-in-MAC T-MPLS VLAN Q-in-Q MAC-in-MAC T-MPLS VLAN Q-in-Q MAC-in-MAC T-MPLS VLAN DUT L2 Switch Ingress Provider Edge Bridge Ingress Provider Backbone Edge Bridge Ingress Carrier Edge Bridge Egress Provider Edge Bridge Provider Core Bridge Ingress Provider Backbone Edge Bridge Ingress Carrier Edge Bridge Egress Provider Backbone Edge Bridge Egress Provider Backbone Edge Bridge Provider Backbone Core Bridge N/A Egress Carrier Edge TMPLS Switch
Table 29-8. Tx VLAN VLAN VLAN VLAN Q-in-Q Q-in-Q Q-in-Q Q-in-Q
MAC-in-MAC MAC-in-MAC MAC-in-MAC MAC-in-MAC T-MPLS
29-24

QoS Test
Table 29-8. Tx T-MPLS T-MPLS T-MPLS
Traffic Flow Combinations (Continued) Rx Q-in-Q MAC-in-MAC T-MPLS DUT Egress Carrier Edge TMPLS Switch N/A Carrier Core T-MPLS Switch
Test Setup
The Test Setup tab contains the following tabs: Run Parameters on page 29-25. Client and Q-in-Q Parameters on page 29-28. Carrier Network Parameters on page 29-31.
Run Parameters
Figure 29-16.Run Parameters
Duration - the transmit duration per iteration can be specified. Test Parameters: No. of trials - number of trials to be executed in the test Calculate Latency - if checked the latency measurements will be done. Calibrate Latency - if checked the latency calibration will be performed; enabled only if Calculate Latency is checked.
29-25
29

QoS Test
Latency Type - specify the method for calculating latency (Cut Through/ Store and Forward); enabled only if Calculate Latency is checked. Staggered Transmit - if checked a 25-30 ms delay is introduced between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, this parameters should be used if the DUT cannot cope with test traffic arriving on all ports at the same time. Sequence Errors - if checked sequence checking measurements are performed and the values reported in the test output Data Integrity - if checked data integrity checking measurements are performed and the values reported in the test output
Iteration - contains the parameter that defines the iteration loop control: Binary radio button - if selected a binary search algorithm is performed to search the throughput rate at which the frame loss is in the tolerance specified and the difference between 2 consecutive iterations is bigger then the resolution. Linear radio button - if selected a linear iteration is performed based on the initial rate value, the number of iterations and the increment step specified No. of iterations - number of linear iterations to be performed when linear iteration is used; enabled only when Linear radio button is selected. Loss Tolerance (%) - the acceptable tolerance for the lost frames when searching the throughput rate; enabled only when Binary radio button is selected. Resolution - the minimum difference between 2 binary search iterations. If the difference is going below the resolution value the binary search algorithm is stopped even if the throughput rate wasn't reached; enabled only when Binary radio button is selected. Init Rate - the initial rate from where the binary search algorithm starts (when Binary radio button is selected) or the used rate for the first linear iteration (when the Linear radio button is selected); the value can be specified in %, fps or kbps (bit rate; without including preamble) depending on the right combo box selection. Increment - the increment step to be used between linear iterations; enabled only when Linear radio button is selected.
Pass Criteria - contains the criteria to be applied per each trial and determine if the trials passed or failed. If multiple criteria are applied the results of all criteria are aggregated in one, and if at least one failed the trial is considered to be failed. Load Rate - Rate at which the DUT should be able to transmit and receive, expressed as a percentage of the maximum theoretical line speed or in terms of kilobits per second, (Kb/s) megabits per second (Mb/s), gigabits per second (Gb/s), frames per second (f/s). Either of the following two methods can be selected to calculate the percentage of lost frames:
29-26

QoS Test
Average/Port: The test averages the frame loss over all ports, and then applies the criteria to determine whether a trial passed or failed. Minimum Port: The test selects the smallest amount of frame loss experienced on each port, and then applies the criteria to determine whether a trial passed or failed.
Pass: The DUT transmitted or received frames at a rate equal to or greater than the rate entered. Fail: The DUT transmitted or received frames at a rate lower than the rate entered. Latency - the amount of time required by the DUT to forward frames. In order to specify the time units, nanoseconds (ns), microseconds (us), or milliseconds (ms) can be selected from the drop-down list. Either of the following two methods can be selected to calculate the latency: Average/Port: The test averages the latency over all ports, and then applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the longest latency experienced on each port, and then applies the criteria to determine whether a trial passed or failed.
Pass: The latency was less than or equal to the time specified. Fail: The latency exceeded the time specified. Total Sequence Errors - the number of frames received with sequence errors. Either of the following two methods can be selected to calculate the sequence errors: Average/Port: The test averages the frames received with sequence errors over all ports, and then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with sequence errors on each port, and then it applies the criteria to determine whether a trial passed or failed.
Pass: The number of frames received with sequence errors was equal to or lower than the number entered. Fail: The number of frames received with sequence errors was greater than the number entered. Total Data Integrity Errors - the number of frames received with CRC errors. Either of the following two methods can be selected to calculate the CRC errors: Average/Port: The test averages the frames received with CRC errors over all ports, and then it applies the criteria to determine whether a trial passed or failed. Maximum Port: The test selects the largest number of frames received with CRC errors on each port, and then it applies the criteria to determine whether a trial passed or failed.
Pass: The number of frames received with CRC errors was less than or equal to the number entered.
29-27
29

QoS Test
Fail: The number of frames received with CRC errors was greater than the number entered
Client and Q-in-Q Parameters

Figure 29-17 illustrates the Client and Q-in-Q Parameters dialog box.
Figure 29-17.Client and Q-in-Q Parameters
Client Parameters: C-Tag - this parameter is available only for MAC-in-MAC and T-MPLS traffic types to select if C-Tag should be included in the frame. This parameter won't be used for VLAN and Q-in-Q traffic. First C-Vlan ID - the id of C-Tag of the first Customer Equipment (CE). Default: 100. No. of C-Tags per port - the number of C-Tags on a physical port. Represents the number of emulated CEs on a physical port. Default: 1. Increment by - the increment step for Vlan ID between the emulated CEs on a port, and between the CEs emulated on different ports. Default: 1
29-28

QoS Test
No. of MAC Addresses - the number of addresses emulated per each CE. Default: 1 C-Tag Ethernet Type - the Ethernet Type that is set in the C-Tag frame. Available values: 0x8100, 0x88a8, and user defined. Default: 0x8100 Source MAC Address: First Address - the MAC address of the first address of the first CE emulated on the first tx port. Default: 00 CE EF DB 00 01 Increment by - the increment specified in MAC format between the addresses on the same CE on a tx port, between the addresses on CEs on the same tx port and between the addresses on the CEs on the emulated on all tx ports. Default: 00 00 00 00 00 01
Unicast Destination MAC Address: First Address - the unicast MAC address of the first address of the first CE emulated on the first rx port. Default: 00 CE EF DC 00 01 Increment by - the increment specified in MAC format between the addresses on the same CE on a rx port, between the addresses on CEs on the same rx port and between the addresses on the CEs on the emulated on all rx ports. Default: 00 00 00 00 00 01
C-Tag Priority - the required C-Tag priorities are selected and the CFI bit for each of the selected priority. Default: 1 selected (all CFI: 0).
Q-in-Q Parameters: S-Tag - this parameter is available only for MAC-in-MAC and T-MPLS traffic types to select if S-Tag should be included in the frame. This parameter won't be used for Q-in-Q traffic. First S-Vlan ID - the id of the S-Tag of the first emulated Provider Edge (PE). Default: 1000. No. of S-Tags - the number of S-Tags on a physical port. Represents the number of emulated PEs on a physical port. Default: 1. Increment by - the increment step for Vlan ID between the emulated PEs on a port, and between the PEs emulated on different ports. Default: 1. S-Tag Ethernet Type - the Ethernet Type that is set in the S-Tag frame. Available values: 0x8100, 0x88a8, and user defined. Default: 0x8100 S-Tag Priority - the required S-Tag priorities are selected and the DEI bit for each of the selected priority. Default: 1 selected (all DEI: 0).
NOTES: The mapping between the C-Tags and S-Tags per port it will be done by distributing the C-Tags in order to each S-Tag in order. The mapping between the C-Tags and priorities is each one C-Tag to all priorities. The mapping between the S-Tags and priorities is each one S-Tag to all priorities.
Example (refer to Table 29-9 for C-Tag and S-Tag mapping):
29-29
29

QoS Test
First C-Vlan ID: 200 No. of C-Tags per port: 5 Increment C-Tag Vlan: 1 List of selected priorities for C-Tag: 0 (CFI: 0), 2 (CFI: 1), 6 (CFI: 0). First S-Vlan ID: 1000 No. of S-Tags per port: 2 Increment S-Tag Vlan: 1 List of selected priorities for S-Tag: 1 (DEI: 1), 4 (DEI: 0).
Table 29-9. C-Tag 200 200 200 200 200 200 201 201 201 201 201 201 202 202 202 202 202 202 203 203 203 203 203 203 0 0 2 2 6 6 0 0 2 2 6 6 0 0 2 2 6 6 0 0 2 2 6 6 C-Tag and S-Tag Mapping Example C-Tag Priority 0 0 1 1 0 0 0 0 1 1 0 0 0 0 1 1 0 0 0 0 1 1 0 0 CFI S-Tag 1000 1000 1000 1000 1000 1000 1001 1001 1001 1001 1001 1001 1000 1000 1000 1000 1000 1000 1001 1001 1001 1001 1001 1001 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 S-Tag Priority 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 DEI
29-30

QoS Test
Table 29-9. C-Tag 204 204 204 204 204 204
C-Tag and S-Tag Mapping Example (Continued) C-Tag Priority 0 0 2 2 6 6 0 0 1 1 0 0 CFI S-Tag 1000 1000 1000 1000 1000 1000 1 4 1 4 1 4 S-Tag Priority 1 0 1 0 1 0 DEI
Carrier Network Parameters

Figure 29-18 illustrates the Carrier Network Parameters dialog box.
Figure 29-18.Carrier Network Parameters
MAC-in-MAC Parameters:
29-31
29

QoS Test
First B-Vlan ID - the id of B-Tag of the first Provider Backbone Bridge. Default: 2000. No. of B-Tags per port - the number of B-Tags on a physical port. Represents the number of emulated Provider Backbone Bridges on a physical port. Default: 1. Increment B-Tag Vlan - the increment step for Vlan ID between the emulated Provider Backbone Bridges on a port and between the Provider Backbone Bridges emulated on different ports. Default: 1 First I-SID - the ID of the I-Tag associated with the first pair of C-tag/Stag. If C-Tag is not enabled in the stream, this is the ID of the I-Tag associated with the first S-Tag. If S-tag is not enabled in the stream, this is the ID of the I-Tag associated with the first C-Tag. Default: 10. Increment I-SID - the increment step for I-SID between the B-Tags. Default: 1 Backbone SA MAC Address: First Address - the MAC address of the first address of the first Provider Backbone Bridges emulated on the first tx port. Default: 00 DE EF DB 00 01 Increment by - the increment specified in MAC format between the addresses of Provider Backbone Bridges emulated on the same tx port and between the addresses on the Provider Backbone Bridges emulated on different tx ports. Default: 00 00 00 00 00 01
NOTE: Currently the test supports only one Provider Backbone Bridge emulated per physical port.
Backbone DA MAC Address: First Address - the MAC address of the first address of the first Provider Backbone Bridges emulated on the first rx port. Default: 00 DE EF DC 00 01 Increment by - the increment specified in MAC format between the addresses on Provider Backbone Bridges emulated on the same rx port and between the addresses on the Provider Backbone Bridges emulated on different rx ports. Default: 00 00 00 00 00 00.
NOTE: Currently the test supports only one Provider Backbone Bridge emulated per physical port.
I-Tag Priority/DEI - the required I-Tag priorities are selected and the DEI bit for each of the selected priority. Default: 1 selected (all DEI: 0).
29-32

QoS Test
NOTES: The mapping between the C-Tags, S-tags, B-tags and I-tags per port is done by distributing the S-tags/C-Tag pairs in order to each B-Tag in order following the number of S-tags and by distributing the S-tags/C-Tag pairs in order to each I-Tag in order following the number of C-Tags. The mapping between the C-Tags and priorities is each C-Tag to all priorities. The mapping between the S-Tags and priorities is each S-Tag to all priorities. The mapping between the I-Tags and priorities is each I-Tag to all priorities. Each B-Tag is configured with the priority of the corresponding I-Tag.
Example (refer to Table 29-10 for C-Tag, S-Tag, B-Tag, and I-Tag mapping): First C-VLAN ID: 101 No. of C-Tags per port: 4 Increment C-Tag VLAN: 1 List of selected priorities for C-Tag: 0 (CFI: 0), 2 (CFI: 1) First S-VLAN ID: 201 No. of S-Tags per port: 3 Increment S-Tag VLAN: 1 List of selected priorities for S-Tag: 1 (DEI: 0), 3 (DEI: 1) First B-VLAN: 301 No. of B-Tags per port: 2 Increment B-Tag VLAN: 1 First I-SID: 10 Increment I-SID: 1 List of selected priorities for I-Tag: 2(DEI: 1), 4 (DEI: 0)
Table 29-10. C-Tag, S-Tag, B-Tag, and I-Tag Mapping Example C-Tag C-VLAN 101 101 101 101 101 101 101 101 102 102 102 102 Priority 0 0 0 0 2 2 2 2 0 0 0 0 CFI 0 0 0 0 1 1 1 1 0 0 0 0 S-VLAN 201 201 201 201 201 201 201 201 202 202 202 202 S-Tag Priority 1 1 3 3 1 1 3 3 1 1 3 3 DEI 0 0 1 1 0 0 1 1 0 0 1 1 B-Tag B-VLAN 301 301 301 301 301 301 301 301 302 302 302 302 I-SID 10 10 10 10 10 10 10 10 11 11 11 11 I-Tag Priority 2 4 2 4 2 4 2 4 2 4 2 4 DEI 1 0 1 0 1 0 1 0 1 0 1 0
29-33
29

QoS Test
Table 29-10. C-Tag, S-Tag, B-Tag, and I-Tag Mapping Example (Continued) C-Tag C-VLAN 102 102 102 102 103 103 103 103 103 103 103 103 104 104 104 104 104 104 104 104 Priority 2 2 2 2 0 0 0 0 2 2 2 2 0 0 0 0 2 2 2 2 CFI 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 S-VLAN 202 202 202 202 203 203 203 203 203 203 203 203 201 201 201 201 201 201 201 201 S-Tag Priority 1 1 3 3 1 1 3 3 1 1 3 3 1 1 3 3 1 1 3 3 DEI 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 B-Tag B-VLAN 302 302 302 302 301 301 301 301 301 301 301 301 301 301 301 301 301 301 301 301 I-SID 11 11 11 11 12 12 12 12 12 12 12 12 13 13 13 13 13 13 13 13 I-Tag Priority 2 4 2 4 2 4 2 4 2 4 2 4 2 4 2 4 2 4 2 4 DEI 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
T-MPLS Parameters: First TMP Label ID - the first TMP label id of the first T-MPLS switch. Default: 16. Increment By - the increment step for TMP label ids between the emulated T-MPLS switches on a port and between the T-MPLS switches emulated on different ports. Default: 1 First TMC Label ID - the first TMC label id of the first T-MPLS switch. Default: 16. Increment By - the increment step for TMP label ids between the emulated T-MPLS switches on a port and between the T-MPLS switches emulated on different ports. Default: 1 No. of Labels - the number of labels on a physical port. Represents the number of emulated T-MPLS switch on a physical port. Default: 1.
29-34

QoS Test
T-MPLS SA MAC Address: First Address - the MAC address of the first address of the first TMPLS switch emulated on the first tx port. Default: 00 FE EF DB 00 01 Increment by - the increment specified in MAC format between the addresses on T-MPLS switches emulated on the same tx port and between the addresses on the T-MPLS switches emulated on different tx ports. Default: 00 00 00 00 00 01
T-MPLS DA MAC Address: First Address - the MAC address of the first address of the first TMPLS switch emulated on the first rx port. Default: 00 FE EF DC 00 01 Increment by - the increment specified in MAC format between the addresses on T-MPLS switches emulated on the same rx port and between the addresses on the T-MPLS switches emulated on different rx ports. Default: 00 00 00 00 00 00
T-MPLS Labels Priority (EXP Bit) - the required Label EXP Bits are selected. Default: 1.
NOTES: The mapping between the C-Tags, S-Tags, and T-MPLS labels per port is done by distributing the S-Tag/C-Tag pairs in order to each TMP/TMC label pair in order following the number of S-tags. The mapping between the C-Tags and priorities is each C-Tag to all priorities. The mapping between the S-Tags and priorities is each S-Tag to all priorities. The mapping between the TMP/TMC label pairs and the EXP bits is each TMP/TMC pair to all EXP bits.
Example (refer to Table 29-11 for C-Tag, S-Tag, and T-MPLS label mapping): First C-Vlan ID: 101 No. of C-Tags per port: 4 Increment C-Tag Vlan: 1 List of selected priorities for C-Tag: 0 (CFI: 0), 2 (CFI: 1) First S-Vlan ID: 201 No. of S-Tags per port: 3 Increment S-Tag Vlan: 1 List of selected priorities for S-Tag: 1 (CFI: 0), 3 (CFI: 1) First TMP Label ID: 16 Increment TMP Label: 1
29-35
29

QoS Test
First TMC Label ID: 10000 Increment TMC Label: 1 List of selected EXP bits: 1, 4
Table 29-11. C-Tag, S-Tag, and TMPLS Label Mapping Example C-Tag C-VLAN 101 101 101 101 101 101 101 101 102 102 102 102 102 102 102 102 103 103 103 103 103 103 103 103 104 104 104 Priority 0 0 0 0 2 2 2 2 0 0 0 0 2 2 2 2 0 0 0 0 2 2 2 2 0 0 0 CFI 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 S-VLAN 201 201 201 201 201 201 201 201 202 202 202 202 202 202 202 202 203 203 203 203 203 203 203 203 201 201 201 S-Tag Priority 1 1 3 3 1 1 3 3 1 1 3 3 1 1 3 3 1 1 3 3 1 1 3 3 1 1 3 DEI 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 TMP Label 16 16 16 16 16 16 16 16 17 17 17 17 17 17 17 17 16 16 16 16 16 16 16 16 16 16 16 T-MPLS TMC Label 10000 10000 10000 10000 10000 10000 10000 10000 10001 10001 10001 10001 10001 10001 10001 10001 10000 10000 10000 10000 10000 10000 10000 10000 10000 10000 10000 EXP Bit 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1 4 1
29-36

QoS Test
Table 29-11. C-Tag, S-Tag, and TMPLS Label Mapping Example (Continued) C-Tag C-VLAN 104 104 104 104 104 Priority 0 2 2 2 2 CFI 0 1 1 1 1 S-VLAN 201 201 201 201 201 S-Tag Priority 3 1 1 3 3 DEI 1 0 0 1 1 TMP Label 16 16 16 16 16 T-MPLS TMC Label 10000 10000 10000 10000 10000 EXP Bit 4 1 4 1 4
Results
The test results are reported as follows: Results on page 29-37. Aggregate Results on page 29-38. Iteration on page 29-38.
Results
Results.csv contains the following information:
Trial Frame size Iteration (only when linear search is selected) Tx Port Rx Port C-Tag Priority/S-Tag Priority B-Tag/I-SID Priority (only for MAC-in-MAC) MPLS Priority (only for T-MPLS) Throughput Frame Rate Tx Rate (Mbps) Tx Count Rx Count Frame Loss Frame Loss % Latency (Min Latency, Avg Latency, Max Latency) Sequence Errors (Small Seq Errors, Big Seq Errors, Revert Seq Errors, Total Seq Errors)
29-37
29

QoS Test
Data Integrity Errors
Aggregate Results
AggregateResults.csv contains the following information:
Trial Frame size Iteration (only when linear search is selected) Throughput Frame Rate Tx Rate (Mbps) Tx Count Rx Count Frame Loss Frame Loss % Latency (Min Latency, Avg Latency, Max Latency) Sequence Errors (Small Seq Errors, Big Seq Errors, Revert Seq Errors, Total Seq Errors) Data Integrity Errors
Iteration
When binary search is selected Iteration.csv contains the following information: Trial Frame size Iteration Tx Port Rx Port C-Tag Priority/S-Tag Priority B-Tag/I-SID Priority (only for MAC-in-MAC) MPLS Priority (only for T-MPLS) Throughput Frame Rate Tx Rate (Mbps) Tx Count Rx Count
29-38

QoS Test
Frame Loss Frame Loss % Latency (Min Latency, Avg Latency, Max Latency) Sequence Errors (Small Seq Errors, Big Seq Errors, Revert Seq Errors, Total Seq Errors) Data Integrity Errors
29-39
29

QoS Test
29-40
30
Chapter 30:
IxGreen Test Suite
Table 30-1describes terms you need to know for this chapter.

Table 30-1. Term voltage Definition For DC current: The electrical potential difference between two points measured in volts (V), where V = I*R, the product of the current and the resistance. For AC current: The electrical potential difference between two points measured in volts (V), where
RV = I ----------- and where phy is the phase difference cos
between I and V. current power The movement of electric charge measured in amperes (A). For DC current: The transmission rate of electrical energy. Real power (also know as true power and effective power) is measured in watts (W). It is the power consumed when one ampere flows through a resistance of one ohm. It is also the product of amperes and the RMS voltage (Vrms), which is voltage measured in root mean square. For AC current: The transmission rate of electrical energy. Real power (also know as true power and effective power) is measured in watts (W). It is the net transfer of energy in one direction over a complete cycle of the AC waveform.
The IxGreen test suite consists of: Test System Setup on page 30-2. Test Configuration on page 30-2. Test Cycle on page 30-7. Statistics on page 30-7.
30-1
30
IxGreen Test Suite

Test System Setup
Test System Setup

Figure 30-1 illustrates the components of the test system for IxGreen.
Figure 30-1. Test Harness Diagram
In order to take power measurements, a power meter device is needed. The power meter needs to have network connectivity. The power statistics are retrieved from the power meter by Telnet.
Test Configuration
This section covers the following topics: Port Setup on page 30-2. Traffic Setup on page 30-2. Test Setup on page 30-3.
Port Setup Traffic Setup
For information about configuring ports, refer to Chapter 3, Creating and Running IxAutomate Tests. The traffic Setup contains the Frame Size, Learning Frames, Frame Data and Traffic Map configuration regions.
30-2
IxGreen Test Suite

Test Configuration
Figure 30-2. Traffic Setup Dialog Box
Frame Size Only Imix frame size mode is supported. For more information, refer to Imix Mode on page 3-48.
Learning Frames For information, refer to Configuring Learning Frames on page 3-23.
Frame Data Protocols supported: IP, IPV6. Get Addresses using DHCP support.
Traffic Map Both Manual and Automatic modes are supported. Unidirectional and Bidirectional modes are supported only for Automatic mode. A one to one mapping is used.
Test Setup
30-3
30
IxGreen Test Suite

Test Configuration
Figure 30-3. Run Parameters
Run Parameters
Power Measurement Duration this section will include the timing values for the power measurement iterations. Ramp Up delay (seconds) the wait time (in seconds) before starting power measurements from starting transmitting traffic. Default: 10. Measuring Duration - duration while the traffic is transmitted and the power measurements are performed. It is configured in hours:minutes:seconds format. Default: 4 minutes. Ramp Down delay (seconds) the wait time (in seconds) before stopping the power measurements and the complete termination of traffic (end of iteration). Default: 10. The traffic transmission duration includes Ramp up delay, measuring duration, Ramp down delay. Polling interval the interval of time (in seconds) needed to wait until another call to the power meter for statistics will be sent. This is valid for Telnet statistics retrieval. Default: 2.
NOTE: Because each client machine needs to process the data from each poll, the processing time depends on the client machine processing power.
30-4
IxGreen Test Suite

Test Configuration
Test Parameters
This section defines the iteration parameters used during power measurement. For details about the advanced setup parameters see Advanced Parameters on page 4-7. Test Segmentation Mode this defines the mode of splitting the rate in multiple iterations. Automatic: a number of iterations will be performed as specified by the user. First iteration will run with the Starting Load (% of Max) rate value and the last iteration will run with the Ending Load (% of Max) rate value. The intermediate iterations will run with values split equally between the 2 values. This is the default setting. Manual: the test will run one iteration for each rate value in the Load List (% of Max).
Starting Load (% of Max) percent ratio from the rate defined/found during test calibration used as starting rate value for the power measurement iterations. Default: 100. Number of Iterations - number of iterations performed for power measurements. Default: 3. Ending Load (% of Max) percent ratio from the rate defined/found during test calibration used as ending rate value for the power measurement iterations. Default: 0. Load List (% of Max) list of percent ratios from the rate defined/ found during test calibration used as rate values for the power measurement iterations. Default: 100, 50, 0. DUT Processing Delay - the time allowed for DUT processing before traffic transmit. Default: 0. Staggered Transmit - if checked a 25-30 ms delay is introduced between the time one port begins transmitting and the time the next port begins transmitting. If you do not check this box, all ports begin transmitting at the same time. Typically, this parameter should be used if the DUT cannot cope with test traffic arriving on all ports at the same time. Default: unchecked.
Test Calibration
This section describes the parameters used for calibration to get the starting rate for power measurements iterations when Automatic segmentation mode is used. Calibration Mode defines the mode for finding the starting rate. Automatic Search: a binary search algorithm is performed to find the throughput rate in the tolerance value defined and starting with the initial rate configured. This is the default selection. User: no binary search is performed. User defines the starting rate for power measurement iterations.
30-5
30
IxGreen Test Suite

Test Configuration
Binary Search defines the binary search mode is performed. Linear: binary search is performed across all ports. The rate is increased or decreased in the same time on all ports. The rate is increased on all ports if none of the ports has loss; the rate is decreased on all port if at least one port has loss. This is the default selection. Per Port: binary search is performed for each port individually. The rate is decreased on one port if it has loss; otherwise the rate is increased on that port.
User Load Rate: rate defined by the user as the starting rate for power measurement iterations when the calibration mode is set on User; the value can be specified in percent, fps or kbps (bit rate; without including preamble) depending on the right combo box selection. Default: 100. Init Rate: the initial rate from where the binary search algorithm starts; the value can be specified in percent, fps or kbps (bit rate; without including preamble) depending on the right combo box selection. Default: 100. Loss Tolerance (%) the acceptable tolerance for the lost frames when performing binary search algorithm. Default: 0.
Power Device Settings.

This section describes the power device settings. Address the IP address of the power meter. Default: no default. Login the user name needed for connecting to the power meter. Default: no default. Password the password needed to connect to the power meter. Default: no default. Retrieve Power Data. User can choose what power data to be measured. Power Default: Enabled. Apparent power Default: Disabled. Current Default: Disabled. Voltage Default: Disabled.
Offset at Idle if selected the value configured will be subtracted from the Power and/or Apparent Power data values retrieved. Default: unchecked.
Note: The Total Power is calculated using the formula: PTotal = (0.35 x Pmax) + (0.4 x P50) + (0.25 x Pidle). The test will consider Pmax the power measured at the first measurement rate, P50 the power measured at the middle measurement rate, and Pidle the power measured at the last measurement rate.
30-6
IxGreen Test Suite

Test Cycle
Test Cycle
The test proceeds as follows: Perform Layer 1 configuration, transmit and receive modes configuration, send learning frames/ARP/ND. Perform calibration process to determine maximum throughput. This step is skipped if the calibration mode is set to User. Compute intermediate measurement targets. Iterate to perform power measurements: Traffic is transmitted at throughput interval X, where X begins at the highest target throughput and reduces each iteration until a zero-throughput point can be measured, to obtain an Active-Idle measurement. Delay a number of seconds. Start power measurements. Collect power and performance metrics. End collection of performance and power measurements. By default, each iteration lasts for 240 seconds (not including the ramp up and ramp down periods). Delay a number of seconds.
End all measurements. Post-process performance and power data.
Statistics
Test results are reported as follows: Green Power Results on page 30-7. Green Power Performance Results on page 30-8. Green Polling Results on page 30-8. PDF Reports on page 30-9.
Green Power Results
File green-results.csv is generated for each test and contains the power measurements for the test: Iteration. RampUp Delay. Measurement Duration. RampDown Delay. Load (%).
30-7
30
IxGreen Test Suite

Statistics
Tx Rate (fps). Tx Rate (Gbps). Active Power. RMS Voltage. RMS Current. Apparent Power. PTotal (W). TEEER. EER (Gbps/kW). ECR (kW/Gbps). ECRW (kW/Gbps). Relative Load.
Green Power Performance Results
File green-performance.csv is generated for each test and contains power and test measurements. Power statistics are synchronized with test iterations. From the AggregateResults.csv of each test, the following is retrieved and aligned with the power measurements: Iteration. Tx Rate (fps). Tx Rate (Gbps). Active Power. RMS Voltage. Apparent Power. PTotal (W). TEEER. EER (Gbps/kW).
Green Polling Results
File green-polling.csv is generated for each test and contains the power measurements for the test that are collected at the polling interval: Iteration. Index. Inner Index. Timestamp. Load (%). Tx Rate (fps). Tx Rate (mbps).
30-8
IxGreen Test Suite

Statistics
Active Power. RMS Voltage. RMS Current. Apparent Power. Relative Load (%).
PDF Reports
The following PDF reports are generated: Product Information Report on page 30-9. Energy Consumption Rating Report on page 30-9. Active Power over Time Report on page 30-10. Active Power over Time per Iteration Report on page 30-10. Active Power vs. Measurement Columns Report on page 30-11. RMS Current vs. Line Load Report on page 30-12. Results Report on page 30-12.
Product Information Report

Figure 30-4 is an example of the Product Information report.
Figure 30-4. Product Information
Energy Consumption Rating Report

Figure 30-5 is an example of the Energy Consumption Rating report.
30-9
30
IxGreen Test Suite

Statistics
Figure 30-5. Energy Consumption Rating
Active Power over Time Report

Figure 30-6 is an example of the Active Power over Time report.
Figure 30-6. Active Power over Time Report
Active Power over Time per Iteration Report

Figure 30-7 is an example of the Active Power over Time per Iteration report.
30-10
IxGreen Test Suite

Statistics
Figure 30-7. Active Power over Time per Iteration
Active Power vs. Measurement Columns Report

Figure 30-8 is an example of the Active Power vs. Measurement Columns report. It shows throughput Mbps, but this chart is generated with the available data, either throughput Mbps and/or throughput Fps and/or some other type of relevant measurement for the test.
Figure 30-8. Active Power vs. Throughput
30-11
30
IxGreen Test Suite

Statistics
RMS Current vs. Line Load Report

Figure 30-9 is an example of the RMS Current vs. Line Load report.
Figure 30-9. RMS Current vs. Line Load
Results Report
Figure 30-10 is an example of the Results report. In this case, power measurements are aligned with the Tx Rate (Mbps).
Figure 30-10.Results Report
30-12
Appendix A:
Tcl/Tk License
The following terms apply to all versions of the core Tcl/Tk releases, the Tcl/Tk browser plug-in version 2.0, and TclBlend and Jacl version 1.0. Please note that the TclPro tools are under a different license agreement. This agreement is part of the standard Tcl/Tk distribution as the file named "license.terms".
Tcl/Tk License Terms

This software is copyrighted by the Regents of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and other parties. The following terms apply to all files associated with the software unless explicitly disclaimed in individual files. The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this software may be copyrighted by their authors and need not follow the licensing terms described here, provided that the new terms are clearly indicated on the first page of each file where they apply. IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
A-1
Tcl/Tk License Terms
GOVERNMENT USE: If you are acquiring this software on behalf of the U.S. government, the Government shall have only "Restricted Rights" in the software and related documentation as defined in the Federal Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2). If you are acquiring the software on behalf of the Department of Defense, the software shall be classified as "Commercial Computer Software" and the Government shall have only "Restricted Rights" as defined in Clause 252.227-7013 (c) (1) of DFARs. Notwithstanding the foregoing, the authors grant the U.S. Government and others acting in its behalf permission to use and distribute the software in accordance with the terms specified in this license.
A-2
Appendix B:
Ixia License Management
A growing number of Ixia software products use a new technique of licensing. Licensing is managed using the Ixia Registration Utility (IRU). The IRU is automatically installed and run with the installation of licensed Ixia products. Ixias license management technique is the means by which Ixia: Ensures that its software is licensed and used appropriately. Allows Ixia customers to centralize and monitor their software usage. Licenses are purchased from Ixia and issued to the customer via e-mail. These licenses must be installed onsite in order for the licensed software to operate correctly. License installation for an Ixia software product can occur either: At the time of the software installation. Sometime after the software installation, but before software usage.
IMPORTANT Licensed software cannot be used until the licensing process is complete.
The licensing operation is accomplished with a simple wizard process and can be run from: The same computer on which the software was installed, or Some other Windows-based PC. The computer used to perform the licensing process must be connected to the Ixia chassis and workstations in the lab environment. If at all possible, it should also be connected to the Internet. If simultaneous connections to the lab network and Internet are not feasible, it is still possible to complete all licensing operations; the process for off-line installation is covered in the License Management User Guide.
B-1
Types of Licenses
Types of Licenses
Depending on the Ixia product, there are two types of licenses that can be purchased: A node-locked license this type of license is locked to a particular chassis or workstation, and allows only certain software functions to run on that chassis or workstation. A floating license this type of license is stored on a License Server, and allows a set number of chassis or workstations to use various software features. All chassis or workstations that are to use this license must be connected to the License Server, and the server must be running for the licensed Ixia product to function. Once the set number of users is reached for a particular license feature, additional users of the product are denied. Both types of licenses are available from Ixia, and can be mixed to provide the best solution for the testing environments needs. The type of license used for the IxAutomate product is a node-locked license.
Date-based versus Version-based Licensing

In the past, licenses were linked to the version of the software being licensed. For example, if a license for IxAutomate 6.00 was purchased, then the license was only good for the 6.00 version of IxAutomate. If IxAutomate was upgraded to version 6.10, a new license was required. This is version-based licensing, and required the customer to frequently update their licenses. From now on, all licenses issued are date-based licenses. Date-based licenses are valid for the entire period of the products service contract. For example, if a license is purchased for IxAutomate 6.00, with a service contract of one year, IxAutomate can be upgraded to a new version (or a service pack) any time during that year without requiring a new license. This requires less customer license management. The new date-based licensing is backward compatible with the old version-based licensing.
Temporary Licenses
Temporary licenses are offered in the event that a purchased license is not yet available. This allows the customer to use purchased applications even if there is a delay in obtaining a valid license. Temporary license have a time limit (measured in days) and become invalid after the time limit expires. Warnings are presented when the term of a license drops below 30 days.
B-2
Types of Licenses
A sample of a temporary license installation are shown in Temporary License Installation on page B-11.
Evaluation Licenses
Evaluation licenses are used to evaluate Ixia software products. They can be used for a limited number of days. They act in all respects as a regular license (they must be installed using the IRU), save for the fact that they have a time limit.
Tcl Notes for use with Licensing

Although the GUI offers the user the ability to create a temporary license, this cannot be offered while running a Tcl script. If a temporary license is required, the IRU should be run independently. If your license resides on the chassis being used by your Tcl program, no adjustment is necessary. If youre using a License Server, please continue reading. Although the GUI offers the user the ability to designate an independent license server as a menu option, no such option is available to a Tcl program. Instead an environment variable named IXN_LICENSE_SERVER must be set. If youre running your Tcl program on a Unix client, the environment variable must be set on the host running the TclServer. If youre running your Tcl program on a Windows client, it must be set on that client. Environment variables are set on a Unix host through the users shell initialization script. Environment variables are set on a Windows host by: 1. Right-click on the My Computer icon on the desktop and then left click on Properties. 2. Choose the Advanced tab from the System Properties dialog box. 3. Press the Environment Variables button at the bottom of the page. 4. In either the User variables for <user> or System variables list, if IXN_LICENSE_SERVER does not exist in the list, press New, otherwise Edit. 5. The name of the variable should be IXN_LICENSE_SERVER and the value should be the name or IP address of the license server machine.
Prerequisites
Before installing a license, obtain the following: The Ixia generated registration email for the licenses being installed. The key contents of this email are: A Registration Number (RN) a unique number for the license. A Password required to install the license. An understanding of which Ixia software products and chassis the license applies to. An and understanding of whether a License Server is used in the Test Lab.
B-3
Types of Licenses
An example of this e-mail is shown below in Figure B-1 on page B-4, with the Registration number and Password underlined:
Dear IxAutomate Customer, License Key Information When you first start IxAutomate, you will need to register your IxAutomate license. When connected to the Internet, you can directly register your copy of IxAutomate by simply running the IRU utility provided by Ixia. For offline registration, the IRU will guide you through the registration process. You will need to use a web browser on a machine connected to the internet. Please record the registration number and password shown below. Product: IxAutomate Features: * IxAutomate, Optional Software, RFC 2544 Test Suite Version: 6.00 Registration Number: 500005484NC Password: lmzjeN Maintenance End Date: 12/12/04 Technical Support from Ixia is available to organizations that are evaluating IxAutomate and to licensed customers who have a valid maintenance agreement with Ixia for IxAutomate. To obtain technical support, go to the IxAutomate support section of Ixia web site: http://www.ixiacom.com/support Alternatively, please contact Ixia at: support@ixiacom.com Domestic: (877) FOR-IXIA International: +1-818-871-1800 (press 1) The Ixia support department is available Monday - Friday from 6:00AM - 6:00PM PST, excluding US holidays Before you start Please be sure to have access to the IxAutomate documentation set, especially the User Guide. All documentation is available on the CD ROM enclosed in the media kit (if ordered) or from the Ixia web site at http://www.ixiacom.com. Sincerely, Your Ixia Product Management Team
Figure B-1.
Example Registration Email
B-4
Installation Scenarios
There are four possible installation scenarios, described in the following sections: Licensing to a Chassis or Workstation via the Internet on page B-5 Licensing to a License Server via the Internet on page B-5 Licensing to a Chassis or Workstation without the Internet on page B-6 Licensing to a License Server without the Internet on page B-6 The Installation Host is the computer that is used to perform the licensing installation. This can be the same computer on which the Ixia software was installed, an Ixia chassis, a License Server, or a separate workstation.
Licensing to a Chassis or Workstation via the Internet
In this case, the Installation Host is connected to the Internet and licenses are installed to the workstation or Ixia chassis to which the license pertains (the workstation and the Installation Host can be the same machine). The Installation Host must also be connected to the workstation/chassis (if they are not the same machine).
Internet
- or Lab Tech
PORTS IN REAR PANEL Sy nc in Sync Out
10/100
Workstation
IXIA
TM
co m un i ca ti on s m
Singlemode OC -48c Load Module Class 1 Laser Device
Freq Monitor
OP1
D C in 0.33V
IXIA
2 T rig 4 Out 6 G nd 2T rig 4 Out 6 Gnd 1 3 5 2 Trig 4 O 6 Gnd ut 2 Trig 4 Out 6 G nd 1 3 5 1 3 5 1 3 5
Dig
P2
Rx
Tx
Er
Tx
ig
lf
IXIA
Err
Trig
Half
Ha
Tr
Err
/Err
Er
Tx
Rx
Rx
Ixia Communications
Installation Host
Port 1
Port 2
Col
Trig
ol
ol
Tx/C
Trig
Co
Tx/C
Tr
Tx/
Tx/
alf
lf
alf
atus
Ha
atus
tus
tus
Ha
lf
Tr
ig
ig
Por 1 t
Por 2 t
Por 3 t
Po
ig
Trig
ig
alf
lf
Tr
Ha
Tr
alf
Ha
Err
Tr
ig
lf
x/Err
Er
1 00
00
Rx/
00
x/
Rx/
10
Er
rt
Po rt 1
Por 3 t
Port 2
Po
IXIA 400T TRAFFIC GENERATOR / PERFORMANCE ANALY ZER
Ixia Chassis
Figure B-2.
Licensing to a Chassis or Workstation via the Internet
Licensing to a License Server via the Internet
In this case, the Installation Host is connected to the Internet and the licenses are installed to a central License Server (the License Server and the Installation Host can be the same machine). The Installation Host must also be connected to the License Server and the workstation/chassis (if the License Server and Installation Host are not the same machine).
rt
LM-10 0TX
oll
ll
ll
L ink
Tx/C
Tx/C
L ink
L ink
Lin
Tx/
Tx/
Coll
Co
L M1000TXS4
Sta
Sta
St
rr
St
Er
L ink
L ink
Lin
Rx/E
Rx/E
Rx/E
Rx/
n i
rr
rr
LM100 0G BIC-2
x/
L/
o l
Rx/
Tx/C
Tx/C
Link
Lin
oll
LMOC 48 VAR
S LO
LOF
PPP
Tx
Rx
VG A use Mo K/B
B-5
Internet
- or PORTS IN REAR PANEL Sy nc in
Workstation
IXIA
TM
c mm uni c ati ons o
Trig 4 O 6 Gnd ut Trig 4 O 6 G ut nd
Lab Tech
S in gle mode OC-4 8c L oad Modu le Class 1 Laser Device
Fre q Mon itor
DC in 0.33V
IXIA
OP2
2 T rig 4 Out 6 Gnd 2T rig 4 Out 6 Gnd 1 3 5 1 3 5 2 1 3 5 2

d nd n
P1
Dig
Rx
Tx
Er
Sync Out
Rx
r ig
IXIA
rr
Rx/E
Rx/E
Err
rr
10/100
Ha
T rig
lf
alf
Po rt 1
Por 2 t
T x/Co
x/Col
r ig
Co
Co
rig
r ig
x/
x/
atus
lf
Half
Half
Statu
Statu
Statu
Ha
Half
rig
Installation Host
Port 2
rt
Por
Po
Po
Ixia Co mmunication s
rig
r ig
Half
T rig
Half
Half
Half
rr
rr
rig
Rx/E
Rx/E
Er
100
Rx/
10
10
Rx/E
100
rr
Port 2
rt
rt
Po
Por
Po
IXIA 400 T TRAFFIC GENERATOR / PERFORMANCE ANALYZER
Ixia Chassis
License Server
Figure B-3.
Licensing to a License Server via the Internet
Licensing to a Chassis or Workstation without the Internet
In this case, the Installation Host is not connected to the Internet and the licenses are installed to the workstation or Ixia chassis to which the license pertains (the workstation and the Installation Host can be the same machine). The Installation Host must also be connected to the workstation/chassis (if they are not the same machine). In order to complete the installation process, an additional computer is necessary an Online Host, as shown in Figure B-4. This machine must be connected to the Internet. It is necessary to transfer small amounts of information from the Online Host to the Installation Host to complete the process. E-mail or a portable USB drive may be appropriate.
Lab Tech
- or Installation Host
PORTS IN REAR PANEL Sync in
Workstation
IXIA
TM
co mmu ni ca tio n s
Singlemode OC-4 8c Load Modul e Class 1 Laser Dev ice
F req Monitor
Dig
D C in 0.33V
IX IA
2 Trig
4 Out 6 Gnd
OP1
Rx
Rx
Err
Tx
Rx
Rx
Tx
Trig
Half
Half
g i
Tx
IX IA
10/100
2 Tri 4 g Ou 6 Gn t
Tr
Er
Er
1 3 5
Sync Out
Por 1 t
o l
o l
Po 2 rt
Trig
Trig
Col
ig
Tx/Co
Tx/C
Tx/C
ig
Statu
Statu
Statu
2 Tr i 4 gO 6 G ut
Tr
Tx/
Half
Half
Half
Half
a tu s
Tr
Po r 1 t
Po r 2 t
Po 3 rt
Ixi a Comm unic ations
ig
Half
Half
ig
i g
Half
Half
Tr
Tr
ig
Po rt 4
2 Tr 4 ig O 6 G ut
Tr
Tr
Err
Err
rr
Rx/E
100
100
Rx/E
100
Rx/
1 0
Rx/
rr
Port
Port 2
Port 3
IX IA 400T TRAF FIC GENERATOR / PERFORMANCE ANALYZER
Ixia Chassis Internet
Online Host
Figure B-4.
Licensing to a Chassis or Workstation disconnected from the Internet
Licensing to a License Server without the Internet
In this case, the Installation Host is not connected to the Internet and the licenses are installed to a License Server (the License Server and the Installation Host can be the same machine). The Installation Host must also be connected to the License Server and the workstation/chassis (if the License Server and Installation Host are not the same machine).
B-6
Port 4
LM- 100TX
ll
Tx/Co
Tx/Co
Tx/Co
Tx/Co
Link
Link
Link
Link
ll
ll
ll
1 3 5
LM1000TXS4
rr
St
Er
Er
Rx/E
Li nk
Li nk
Lin
Rx/E
ink
x/
x/
rr
1 3 5
LM1000GBIC- 2
L/Err
Rx/
Er
o ll
L/
Tx/C
Link
Lin k
Tx/
Coll
Rx/
1 3 5
LMO C48VAR
OP2
LO F
PPP
LOS
Tx
LM-100T X
Coll
ll
ll
x/Co
ink
Link
Tx/
Link
Lin
x/
x/
Coll
Co
1 3 5
LM1 000T XS4
Err
St
x/Err
Err
L ink
ink
Rx/
x/
Lin
rt
Rx/
n i
Err
LM1000GBIC-2
L/Er
L/
x/Co
T x/Co
L ink
Lin
ll
LMOC 48VAR
L OS
OF
PPP
Tx
Rx
VG A use Mo K/B
A VG Mo use K/B
License Installation Example
In order to complete the installation process, an additional computer is necessary an Online Host shown in Figure B-5. This machine must be connected to the Internet. It is necessary to transfer small amounts of information between the Online Host and the Installation Host to complete the process. E-mail or a portable USB drive may be appropriate.
Lab Tech
- or Installation Host
PORTS IN REAR PANEL Sync in
Workstation
IXIA
TM
co mmu ni ca tio n s
Singlemode OC-4 8c Load Modul e Class 1 Laser Dev ice
F req Monitor
OP1
Dig
D C in 0.33V
IX IA
2 Tr
O 4 ut 6 G
Err
Tx
Rx
ig
nd d nd n
Rx
Tx
Trig
Half
Half
g i
Tx
Rx
IX IA
10/100
2 Tri 4 g Ou 6 Gn t
Col ig
Tr
Er
Er
1 3 5
Er r L/ Link Tx/ Coll Rx/ o l Tx/C ig Po 2 rt Statu
Sync Out
Por 1 t
Trig
o l
Tx/Co
Tx/C
Trig
Statu
Statu
2 Tr 4 ig O 6 G ut 2 Tr 4 ig O 6 G ut 1 3 5 1 3 5
Half
Tx/
Half
Half
Half
a tu s
Tr
Tr
Po r 1 t
Po r 2 t
Po 3 rt
Ixi a Comm unic ations
ig
Half
Half
ig
i g
Half
Half
Tr
Tr
Tr
Tr
i g
Po rt 4
Err
Err
100
100
Rx/E
100
Rx/E
Rx/
1 0
Rx/
rr
rr
Port 2
Port
Port 3
IX IA 400T TRAF FIC GENERATOR / PERFORMANCE ANALYZER
Ixia Chassis Internet
Online Host
License Server
Figure B-5.
Licensing to a License Server disconnected from the Internet

The following sections detail a simple online license installation for both a regular and temporary license. Regular License Installation on page B-7. Temporary License Installation on page B-11.
Regular License Installation
The following example shows an online installation of a node-locked license to a local machine, with no license server. Depending on the testing environment, other installations may have more steps.
Note. Depending on whether the license is being installed to a computer or a chassis, the wording in the IRU dialogs is slightly different.
1. If the IRU is not running, start it by selecting Start>Programs>Ixia>Licensing>IRU. 2. Click Register in the IRU, as shown in Figure B-6 on page B-8.
Port 4
LM- 100TX
ll
Tx/Co
Tx/Co
Tx/Co
Tx/Co
Link
Link
Link
Link
ll
ll
ll
LM1000TXS4
St
Er
Er
Li nk
Li nk
Lin
Rx/E
Rx/E
ink
x/
x/
rr
rr
LM1000GBIC- 2
L/Err
Rx/
Tx/C
Lin k
o ll
1 3 5
LMO C48VAR
OP2
LO F LOS
PPP
Tx
A VG Mo use K/B
B-7
Figure B-6.
Licensing Start
3. Click Start. Enter the Registration Number and Password exactly as specified in the Ixia generated e-mail, as shown in Figure B-7.
Figure B-7.
Registration Information
4. Click Next. Enter the host name or IP address of the Ixia chassis or workstation that is to use the licensed software, shown in Figure B-8 on page B-9. Localhost is the default and refers to the Installation Host.
B-8
Figure B-8.
Node Machine
5. Click Next. If a license server is used, click No and enter the name or IP address of the license server. Otherwise, click Yes as shown in Figure B-9.
Figure B-9.
License Server
6. Click Next. Review the information for the license to make sure it is accurate, as shown in Figure B-10 on page B-10.
B-9
Figure B-10. License Installation
7. Click Next. The license is installed to the workstation or chassis specified in Figure B-8 on page B-9 (or to the license server if one was specified in Figure B-9 on page B-9). Once the license is installed, a confirmation screen opens, as shown in Figure B-11. This screen can be printed or saved as a record.
Figure B-11. Finish
8. Click Finish.
B-10
Temporary License Installation
The following example shows an online installation of a temporary license to a local machine, with no license server. Depending on the testing environment, other installations may have more steps. 1. When attempting to use licensed software, and no valid license exists, a temporary license can be issued that allows the software to run for a limited number of days. A dialog similar to Figure B-12 opens in this case.
Figure B-12. Temporary License Prompt
2. Select Yes. The first screen that opens is shown in Figure B-13.
Figure B-13. Temporary License Step 1 Registration Number
3. Configure the following in this dialog: a: Select the correct product from the drop-down list. b: Enter the Company, User Name, and E-mail address. The Node Name is the workstation or chassis where the licensed product is used. The License Location is where the license is installed. Both fields can be a hostname or IP address. In some cases, these default to localhost and cannot be changed.
B-11
c: A valid email address must be entered in the E-Mail field (for example, user@company.com). The email address must be one from the company that is licensing the software. No private email addresses (for example, user@gmail.com) are accepted. d: Click Next. All the necessary information has been entered. A screen similar to the one shown in Figure B-14 opens. Verify the information shown. 4. Click Next to install the license. A license file (extension LIC) is installed on the chassis or workstation specified at step 3. The default installation directory is C:\Program Files\Ixia\licensing\licenses.
Figure B-14. Temporary License Step 2 Save License
5. After the license has been installed, a Receipt similar to the one shown in Figure B-15 displays. This is a record of the licenses registration. Save the information as a file or a printout.
B-12
Figure B-15. Temporary License Step 3 Print Receipt
6. To save the receipt to disk, click the Save Receipt... button and designate a file. To make a printout of the receipt, click the Print Receipt... button and select a printer. 7. Click Finish to exit the registration process. The license is now available for use on the chassis or workstation.
B-13
B-14
Appendix C:
StatViewer Support
This appendix covers the following topics: StatViewer Overview on page C-1. Supported StatViewer Features on page C-1.
StatViewer Overview
StatViewer is an Ixia software component that is used by your application to display test statistics. Depending on your application, StatViewer appears either as a separate window or is embedded in the application. StatViewer provides statistical displays called views. Each view has one or more statistics defined for it, and also includes items such as a title that identifies it, a legend that lists the color used for each statistic, and controls that allow you to change x- and y-axes scales in charts. The views available, the statistics defined for them, and their properties are defined by the applications that send statistics to StatViewer. StatViewer provides default views for each test within an application. As an option, you can select from a list of predefined views and associate them with a test. You can also create your own views for a test, indicating the statistics that are displayed and defining properties such as background color and line style.
Supported StatViewer Features

StatViewer supports a variety of features, but those that are available to you depend on your particular application. StatViewer features and their general operation are defined in the StatViewer User Guide, which is included with your Ixia application. IxAutomate supports the following StatViewer features. Add/Edit/Delete Views StatViewer Controls
C-1
Supported StatViewer Features
Anti-Aliasing Palette Selection 2D / 3D Charts View Rotation Axes Configuration Point Labels Grid Views Legend Displays In and Out Zoom X-Y Delta Specific Statistics in a View (Displays) Statistic Value Displays Sliders Template Management Troubleshooting Generic StatView Paging Csv File Generation HTML Report Format Event Markers Add Linked View to Grid View View Layout Adjustment Application Command Interface Data Store and Replay Default Views Compare Multiple IterationsSNMP Statistics of DUT
C-2
Appendix D:
Diagnostics Support
This chapter covers the following topics: Diagnostics Overview on page D-1. Using Diagnostics on page D-2.
Diagnostics Overview
Diagnostics is an Ixia software component that is used by your application to collect variable, internal information from a chassis and client machine, and wrap it into a ZIP file, for transmission to Ixia. Diagnostics is available via the IxAutomates Help menu.
Figure D-1.
Help Menu
D-1
Using Diagnostics
Using Diagnostics
The Diagnostics tool is used to collect internal information from the chassis or client machine, and optionally send it to one of the Ixia support teams.
Note: It is possible to collect the logs from the client or from the chassis without sending them to Ixia Support.
To use Diagnostics, you must follow these steps: 1. In the case of a problem with an Ixia application that stops functioning, select Send Information to Ixia Support. The pane in Figure D-2 displays.
Figure D-2.
Diagnostics Window
2. Select one of the departments from the Send to drop-down list. You can choose from North America & International Default Technical Support, Europe, Middle East and America Technical Support, India Technical Support, and Asia Pacific Technical Support. 3. In the Customer pane, fill in the Company, Name, E-mail, and Phone fields with the correct information. 4. In the How to reproduce pane, you can enter a short description of the steps to take in order to reproduce the problem you encountered.
Note: You must fill in all the fields before you can start collecting the log information.
D-2
Using Diagnostics
5. Select from the Case Category list whether the problem presented is a hardware or software issue. Optionally, you can enter the Serial Number of the hardware in the SR Number field, as shown in Figure D-2 on page D-2. 6. Optionally, you can select the Collect Files from Client Only check box. The information available on the client machine only is included in the ZIP file. 7. You can optionally select the Select ZIP file location check box in order to change the default location where the ZIP file is saved. The text field becomes available. Click the Browse button and choose the new location where the ZIP file is saved. 8. Click the Show Chassis Selection button to display the ports from which to collect the log information.
Figure D-3.
Chassis List
9. To cancel the operations, click the Cancel button. If you want to continue using Diagnostics, go on to the next step. 10. Disable all the programs that block the connection to the SMTP server, before sending the information to Ixia Support. If these programs are not turned off, an error message displays, as shown in Figure D-4.
Figure D-4.
Upload Error Message
11. Click Start to start collecting the log information to the specified ZIP folder in the chosen location. If the Send Information to Ixia Support option is enabled and there is an FTP upload to the server, a prompt displays after collecting the information, as shown in Figure D-5.
D-3
Using Diagnostics
Figure D-5.
Success Prompt
D-4
Index
A about this guide 1-1 Accumulated test 9-16 Address Cache Size test 6-6 Address Cache test 14-26 Address Rate test 6-8, 14-22 advanced options 4-1 advanced parameters 4-7 Advanced Tcl Script Suite (ATSS) tests 7-1 All Meshed Test 7-49 DTM Random Interval 7-8 Flow Setup 7-10 IP Error 7-12 IP Time to Live 7-34 Layer 2/Layer 3 7-14 Mixed IPv4-IPv6 Throughput 7-46 Multiple Frame Sizes 7-26 Throughput 7-17 Throughput NAT 7-29 Traffic Tester 7-42 VLAN Broadcast Leakage 7-35 VLAN Forwarding 7-56 VLAN Meshed 7-37 VLAN One-to-Many 7-40 Aggregated test 9-19 All Mesh Test 7-49 ATSS tests. see Advanced Tcl Script Suite (ATSS) tests B Back-Pressure test 6-10 Back-to-Back test 5-3 Bandwidth Profile per CoS test 24-27 Bandwidth Profile per Ingress UNI test 24-20 Bandwidth Profile Rate Enforcement test 24-17 Batch Scheduler 3-63 BGP Performance test 18-15 BGP Route Capacity test 18-3 BGP Route Convergence test 18-8 BGP tests. see Border Gateway Protocol (BGP) tests Border Gateway Protocol (BGP) tests 18-1 BGP Performance 18-15 BGP Route Capacity 18-3 BGP Route Convergence 18-8 Broadband Back-to-Back test 21-11 Broadband tests 21-1 Broadband Back-to-Back 21-11 Broadband Throughput 21-7 Broadband Throughput test 21-7 Broadcast Rate test 6-13 Burdened Group Join Delay test 9-78 Burdened Latency test 9-74 C chassis timing source, configuring 4-9 CIR and EIR Combined test 24-23 config directory, importing 2-9 configurations, importing 2-9 configuring chassis timing source 4-9 DUT parameters 3-57 frame sizes 3-45 IP, IPX, and MAC addresses 3-18 StatVeiwer 3-56 test run parameters 3-51 test setup options 3-53
Index-1
Index
creating IxAutomate tests 3-1 custom user code 4-10 customizing the test environment 4-1 D Data Integrity test 8-3 Data Plane test 29-1 Denial of Service Handling test 22-17 device under test. see DUT diagnostics D-1 Distributed test 9-24 documentation, related 1-3 DTM Random Interval test 7-8 DUT parameters, setting up 3-57 E Egress Partially-Meshed Performance test 15-4 Egress Performance test 15-11 Enhanced Quality of Service tests 26-1 Layer 2 QoS 26-7 Layer 3 QoS 26-11 MPLS OSPF QoS 26-16 MPLS QoS 26-21 executing tests 3-62 F FCoE Performance test 28-2 FCoE tests. see Fiber Channel over Ethernet tests features, new in this release 2-6 Fiber Channel over Ethernet tests 28-1 FCoE Performance 28-2 Mixed Class Throughput 28-29 Flow Control 5-35, 6-4, 7-2 Flow Ratio test 11-9 Flow Setup test 7-10 Frame Delay, Frame Delay Variation, Frame Loss Ratio test 24-11 Frame Error Filtering test 6-16 Frame Loss test 5-10 Frame Size Verify Test 8-6 frame sizes, configuring 3-45 Fully-Meshed test 6-17 G Gap Checker test 8-6 graphs, test 3-69 Group Capacity test 9-27 Group Join Delay test 9-31
Group Leave Delay test 9-36 GUI, IxAutomate 2-8 H Head of Line Blocking test 6-14 Help, online 2-4 HTTP Transfer Rate test 22-20 I Illegal Traffic Handling test 22-26 importing configuration files 2-9 Ingress Partially-Meshed Performance test 15-18 Ingress Performance test 15-24 Internet Infrastructure tests 27-1 IP Mesh 27-1 introduction to IxAutomate 2-1 IP addresses, configuring 3-18 IP Error test 7-12 IP Fragmentation Handling test 22-30 IP Mesh test 27-1 IP Multicast (RFC 3918) tests 9-1 Accumulated 9-16 Aggregated 9-19 Burdened Group Join Delay 9-78 Burdened Latency 9-74 Distributed 9-24 Group Capacity 9-27 Group Join Delay 9-31 Group Leave Delay 9-36 Latency 9-40 Mesh 9-45 Mixed Class Throughput 9-55 Scale Group 9-60 Throughput No Drop Rate 9-49 Tunneling Throughput 9-64 IP Throughput test 22-8 IP Time to Live test 7-34 IPv6 Tunneling tests 10-1 Tunnel Capacity 10-2 Tunnel Frame Loss 10-9 Tunnel Throughput 10-12 IPX addresses, configuring 3-18 IS-IS Performance test 19-3 IS-IS tests 19-1 IS-IS Performance 19-3 IxGreen tests 30-1 Ixia license management B-1 L Label Capacity test 16-6
Index-2
Index
Label Distribution Protocol (LDP) tests 15-1 Egress Partially-Meshed Performance 15-4 Egress Performance 15-11 Ingress Partially-Meshed Performance 15-18 Ingress Performance 15-24 Transit Performance 15-30 LACP tests 23-1 LAG to LAG Link Drop 23-21 LAG to LAG Throughput 23-17 Port to LAG Throughput 23-13 LAG to LAG Link Drop test 23-21 LAG to LAG Throughput test 23-17 Latency test 9-40, 22-34 Layer 2 QoS test 26-7 Layer 2 VPN tests 12-1 LDP Egress Performance 12-5 LDP IMIX Performance 12-11 LDP Ingress Performance 12-21 LDP Partially-Meshed Performance 12-27 Martini Sessions Scalability 12-37 Virtual Circuits Scalability 12-43 Layer 2/Layer 3 test 7-14 Layer 3 QoS test 26-11 Layer 3 VPN tests 13-1 Performance and Scalability 13-7 LDP Egress Performance test 12-5 LDP IMIX Performance test 12-11 LDP Ingress Performance test 12-21 LDP Partially-Meshed Performance test 12-27 LDP tests. see Label Distribution Protocol (LDP) tests license management B-1 LSP Cutover test 16-11 M MAC addresses, configuring 3-18 Many-to-Many Mesh test 6-22 Many-to-One test 11-6 Many-to-One Throughput test 6-25 Martini Sessions Scalability test 12-37 MATS. see Multi-port Advanced Test Suite tests (MATS) Maximum HTTP Transaction Rate test 22-23 Maximum TCP Connection Establishment Rate test 22-14 MEF14 tests 24-1 Bandwidth Profile per CoS 24-27 Bandwidth Profile per Ingress 24-20 Bandwidth Profile Rate Enforcement 24-17 CIR and EIR Combined 24-23
Frame Delay, Frame Delay Variation Frame Loss Ratio 24-11 Multiple Bandwidth Profiles at the UNI 24-31 menus and toolbars 2-8 Mesh test 9-45 Metro Performance tests 29-1 Data Plane 29-1 QoS 29-19 Mixed Class Throughput test 9-55, 28-29 Mixed IPv6-IPv6 Throughput test 7-46 MPLS OSPF QoS test 26-16 MPLS QoS test 26-21 MSTP Convergence test 20-8 Multiple Bandwidth Profiles at the UNI test 24-31 Multiple Frame Sizes test 7-26 Multi-port Advanced Test Suite tests (MATS) 8-1 Data Integrity 8-3 Frame Size Verify 8-6 Gap Checker 8-6 Pattern Verify 8-7 Port Loss 8-9 Random Frame Size 8-10 Sequence Verify 8-11 O One-to-Many test 11-7 One-to-Many Throughput test 6-27 online Help 2-4 options, advanced 4-1 OSPF Convergence test 17-3 OSPF Performance test 17-22 OSPF Route Capacity test 17-11 OSPF Route Convergence test 17-16 OSPF tests 17-1 OSPF Convergence 17-3 OSPF Performance 17-22 OSPF Route Capacity 17-11 OSPF Route Convergence 17-16 P parameters, advanced 4-7 Partially-Meshed test 6-29 Partially-Meshed Throughput test 14-13 Pattern Verify test 8-7 Peer-to-Peer Throughput test 14-18 Performance and Scalability test 13-7 Port Loss test 8-9 Port to LAG Throughput test 23-13
Index-3
Index
Q QoS test 29-19 QoS tests. see Quality of Service (QoS) tests QoS, enhanced, tests. see Enhanced Quality of Service tests Quality of Service (QoS) tests 11-1 Flow Ratio 11-9 Many-to-One 11-6 One-to-Many 11-7 R Random Frame Size test 8-10 Resource Reservation Protocol (RSVP) tests 16-1 Label Capacity 16-6 LSP Cutover 16-11 results directory, importing 2-9 results, test 3-69 RFC 2544 - IPv6 Benchmark tests 5-1 Back-to-Back 5-3 Frame Loss 5-10 Throughput 5-27 troubleshooting 5-40 RFC 2889 tests 6-1 Address Cache Size 6-6 Address Rate 6-8 Back-Pressure 6-10 Broadcast Rate 6-13 Frame Error Filtering 6-16 Fully-Meshed 6-17 Head of Line Blocking 6-14 Many-to-Many Mesh 6-22 Many-to-One Throughput 6-25 One-to-Many Throughput 6-27 Partially Meshed 6-29 RFC 3511 tests 22-1 Denial of Service Handling 22-17 HTTP Transfer Rate 22-20 Illegal Traffic Handling 22-26 IP Fragmentation Handling 22-30 IP Throughput 22-8 Latency 22-34 Maximum HTTP Transaction Rate 22-23 Maximum TCP Connection Establishment Rate 22TCP Connections Capacity 22-12 RFC 3918 tests. see IP Multicast (RFC 3918) tests RSVP tests. see Resource Reservation Protocol (RSVP) tests running tests 3-1 using IxAutomate 3-62 using Wish Console 4-12
14
S Scalability test 25-2 Scale Group test 9-60 scheduling test configurations 3-63 scripts, Tcl 2-3 Sequence Verify test 8-11 starting test sessions 3-2 statistics, test 3-69 StatViewer C-1 configuring 3-56 STP Convergence test 20-3 STP tests 20-1 MSTP Convergence 20-8 STP Convergence 20-3 support, technical 1-3 T Tcl commands, inserting 4-10 Tcl scripts 2-3 Tcl/Tk license terms A-1 TCP Connections Capacity test 22-12 technical support for IxAutomate 1-3 test output 3-69 test run parameters, setting up 3-51 test sessions, starting 3-2 test setup options, configuring 3-53 test suites, list of 1-1 tests, scheduling 3-63 Throughput NAT test 7-29 Throughput No Drop Rate test 9-49 Throughput test 5-27, 7-17 toolbars and menus 2-8 Traffic Tester test 7-42 Transit Performance test 15-30 Triple Play tests 25-1 Scalability 25-2 troubleshooting RFC 2544 tests 5-40 Tunnel Capacity test 10-2 Tunnel Frame Loss test 10-9 Tunnel Throughput test 10-12 Tunneling Throughput test 9-64 U user templates, importing 2-9
Index-4
Index
V Virtual Circuits Scalability test 12-43 VLAN Broadcast Leakage test 7-35 VLAN Forwarding test 7-56 VLAN Meshed test 7-37 VLAN One-to-Many test 7-40 VPLS tests 14-1 Address Cache 14-26 Address Rate 14-22 Partially-Meshed Throughput 14-13 Peer-to-Peer Throughput 14-18 VPN, Layer 2, tests. see Layer 2 VPN tests VPN, Layer 3, tests. see Layer 3 VPN tests W whats new in this release 2-6 Wish Console 4-12
Index-5
Index
Index-6

Ix Automate

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ix Automate

Uploaded by

Copyright:

Available Formats

Aptixia IxAutomate User Guide

Part No. 913-0969 Rev D July 21, 2010

Aptixia IxAutomate User Guide, Release 6.90

Creating and Running IxAutomate Tests Customizing the Test Environment

Running IxAutomate Tests Unattended . . . . . . . . . . . . . . . 4-14

RFC 2544 - IPv6 Benchmark Test Suite

RFC 2889 Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Advanced Tcl Script Suite (ATSS)

Aptixia IxAutomate User Guide, Release 6.90

Multi-port Advanced Test Suite (MATS)

IP Multicast (RFC 3918) Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Chapter 10 IPv6 Tunneling Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Chapter 11 Quality of Service (QoS) Test Suite

Chapter 12 Layer 2 VPN Test Suite

Chapter 13 Layer 3 VPN Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Performance and Scalability Test . . . . . . . . . . . . . . . . . . . . 13-7

Chapter 14 VPLS Test Suite

Chapter 15 Label Distribution Protocol (LDP) Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Chapter 16 Resource Reservation Protocol (RSVP) Test Suite

Chapter 17 OSPF Test Suite

Chapter 18 Border Gateway Protocol (BGP) Test Suite

Chapter 19 IS-IS Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Setting Up the Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1 ISIS Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-3

Chapter 20 STP Test Suite

Chapter 21 Broadband Test Suite

Chapter 22 RFC 3511 Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Chapter 23 LACP Test Suite

Chapter 24 MEF14 Test Suite

Chapter 25 Triple Play Test Suite

Chapter 26 Enhanced Quality of Service Test Suite

Aptixia IxAutomate User Guide, Release 6.90

Chapter 27 Internet Infrastructure Test Suite

Chapter 28 Fibre Channel over Ethernet Test Suite

Chapter 29 Metro Performance Test Suite

Chapter 30 IxGreen Test Suite

Appendix A Tcl/Tk License

Aptixia IxAutomate User Guide, Release 6.90

Appendix B Ixia License Management

Appendix C StatViewer Support

Appendix D Diagnostics Support

Aptixia IxAutomate User Guide, Release 6.90

Aptixia IxAutomate User Guide, Release 6.90

About this Guide

Aptixia IxAutomate User Guide, Release 6.90

About this Guide

Aptixia IxAutomate User Guide, Release 6.90

About this Guide

Aptixia IxAutomate User Guide, Release 6.90

About this Guide

Aptixia IxAutomate User Guide, Release 6.90

What is Aptixia IxAutomate?

Aptixia IxAutomate User Guide, Release 6.90

Aptixia IxAutomate User Guide, Release 6.90

What if I want to write my own Tcl scripts?

Aptixia IxAutomate User Guide, Release 6.90