IxExplorer Software
The IxExplorer software utilizes concepts that match the Ixia hardware hierarchy. The software hierarchy is:
- Chassis Chain (Software): A set of Ixia chassis joined through sync-in/sync-out cables.
- Chassis: A single Ixia chassis capable of holding different Ixia module cards.
- Card: An Ixia module card, all of whose ports have the same features.
- Port: An individual transmit/capture port on a card.
- Capture View: A view of the capture buffer for the port.
- Filters, Statistics and Receive Mode: A means of programming capture triggers, filters, and statistics.
- Packet Streams: A means of programming sets of streams and flows.
- Statistics: A view of the statistics gathered by the port.
- Global Views:
- Port Groups: Hold groups of related ports that may be operated on at the same time.
- Stream Groups: Hold groups of related ports that may be operated on at the same time.
- Packet Group Statistic Views: Allows the latency data (including Inter-Arrival Time) to be collected from one or more ports that are configured to receive packet groups.
- Statistic Views: Holds groups of related ports, all of whose statistics can be viewed at one time.
- Stream Statistic Views: Holds groups of related streams, all of whose statistics can be viewed at one time.
- MII Templates: A means of creating and editing MII templates.
- Layouts: A means of saving open GUI features.
- IxRouter Window: A means of designating interface addresses associated with ports and programming routing protocol simulations on each port. Note that IxRouter must be installed for full use of this window. Without IxRouter, only limited use of ARP and PING are allowed. See IxRouter User Guide for more information.
Chassis Chain (Software)
The IxExplorer chassis chain corresponds to the hardware chain. The chain starts with a master, whose sync-out line is connected to the sync-in line of the next chassis, and so on. Multiple chassis chains may be defined in the IxExplorer and operated independently or at the same time. Various forms of time synchronization may be used to coordinate multiple chassis chains dispersed world-wide into a single `virtual chassis chain'; see Chassis Synchronization.
Chassis
The IxExplorer chassis corresponds to an Ixia 400T, Optixia XM12, Optixia XM2, or other chassis capable of holding Ixia module cards. The name or IP address of each chassis must be input; the type of the chassis is automatically discovered by the software. A chassis may hold any mix of module cards.
Card
The IxExplorer card corresponds to an Ixia load module card. The types of cards loaded in a chassis are automatically discovered and the appropriate number of ports are inserted into the hierarchy. Each port on a card has the same capabilities.
Port
The IxExplorer port corresponds to an individual port on an Ixia module card. Each port is independently programmed in terms of its transmit, capture and statistics capabilities. The IxExplorer software shows four separate views for programming and viewing operations:
- Filters, Statistics and Receive Mode: Sets the trigger and capture conditions for the capture buffer, conditions for the four user-defined statistics, and the receive mode for the port.
- Packet Streams/Flows: Defines the streams within stream regions and the contents of packets.
- Capture View: Shows the data gathered during capture operations. Data is displayed in raw form and interpreted for some protocols.
- Statistics : Shows the live statistics gathered during transmit and capture operation.
Port Properties
A Port Properties dialog allows other port related properties to be programmed:
- Auto-Negotiation: Low level physical controls, such as 10 versus 100 Mbps operation and full duplex versus half duplex.
- Advanced MII controls: Additional low level MII register controls.
- Flow control: Related to pause control operation.
- Collision Backoff Algorithm: Handling of collision situations.
- Forced Collisions: The generation of collision packets on receive ports.
- Transmit mode: The choice of streams or flows for the port.
- SONET Header: For use with Packet Over SONET frames.
- SONET Overhead: For generation of APS (K1/K2), J0/J1 bytes, and Error Insertion.
- PPP: For use with SONET. Includes dialogs for Negotiation, Link Control Protocols, and Network Control Protocols.
Port Groups
Port groups are an IxExplorer convenience. They allow to perform operations, such as start/stop transmit, start/stop capture and clear timestamps, for a wide range of ports all at the same time.
Stream Groups
Stream groups are an IxExplorer convenience. They allow to perform operations, such as start/stop transmit, start/stop capture and clear timestamps, for a group of streams all at the same time.
Packet Group Statistic Views
The Packet Group Statistics View allows the latency data (including Inter-Arrival Time) to be collected from one or more ports that are configured to receive packet groups. Packets representing different types of traffic profiles can be associated with packet group identifiers (PGIDs). The receiving port measures the minimum, maximum, and average latency in real time for each packet belonging to different groups. Measurable latencies include Instantaneous Latency, where each packet is associated with one group ID only, and Latency Over Time, where multiple PGIDs can be placed in `time buckets' with fixed durations.
Statistic Views
Statistic Views are similar to port groups, in that they let you consider a set of ports all at once. When a Statistic View group is selected, all of the statistics for all of the ports are simultaneously viewed. The particular statistics viewed may be independently selected for each Statistic View. Statistic logging and alerts are also provided; see Statistics Logging and Alerts.
Stream Statistic Views
Stream Statistic Views are like Statistic Views, but on a per stream basis rather than per port basis.
MII Templates
Allows for the creation and/or editing of MII template files. Register templates are applied to physical ports through Port Properties dialogs.
Layouts
Allows for the creation of templates for the layout of the IxExplorer GUI. A layout consists of the combined open features in the GUI.
IxRouter Window
The IxRouter window provides the means by which routing protocols are emulated by the Ixia hardware and software. This window includes the interface by which multiple IPv4 and IPv6 interfaces are associated with each port. A growing number of protocols are supported in this window, including ARP, BGP, OSPF, ISIS, RSVP-TE, LDP, RIP, RIPng, and IGMP.
Note that full use of this window requires that IxRouter be installed. For more information on protocols and protocol testing, see IxRouter User Guide.
IxExplorer Operation
IxExplorer saves all settings and programming in `saved' named files, which may be retrieved on each invocation. Captured data is lost when the IxExplorer is exited.
All IxExplorer test operations perform on an arbitrary set of ports, as single port or multiple ports may be selected. Any level of the hierarchy may be selected to include all ports below that level. For example, selecting a card includes all ports on that card, or selecting a chassis chain includes all ports on all cards in all chassis in the chassis chain. In addition, port groups may contain ports from any card; the port group may then be used in any testing operations.
The operations that can be performed on any group of ports:
- Start/Stop Capture: When capture is enabled, data for each port that is configured for capture (versus latency) is collected when the trigger is satisfied and to the extent that the filter is satisfied as well.
- Start/Stop Transmit: When transmit is enabled, data is transmitted as programmed to the extent designated by the synchronous stream region.
- Start/Stop Collision: Forced collisions are enabled/disabled for receive ports.
- Start/stop Latency: When latency measurement is enabled, data for each port configured for latency (versus capture) is collected when the trigger is satisfied and to the extent that the filter is satisfied as well.
- Pause/Single-Step Transmit: Transmittal of information may be paused and then single-stepped on a stream-by-stream basis or continued through a start transmit command.
- Interactive streams: This is a special function that allows for interactive variation of frame size and inter-packet gaps. Interactive streams may not be operated across ports that are configured for flows.
Multi-User Operation
IxExplorer provides an optional means of coordinating the sharing of chassis ports among multiple users. If a single user is operating a chassis, multi-user commands are not required at all. As an user, you may perform any operation on any port. Two or more people may also share ports on a chassis without use of IxExplorer multi-user facilities, through some verbal agreement (for example, `You take cards 1-8 and I'll take cards 9-16'). IxExplorer provides no assistance in this instance.
Where more accurate control over port sharing is required, multi-user facilities should be used. IxExplorer's multi-user model is a very simple, advisory model. Each user logs in with an arbitrary name. Each and every user may take ownership of any and all ports. A port owner has the ability to read data and program the port; all other users have read-only access to the port. A port owner may clear ownership of ports, making them available for other users. You may take ownership of a port owned by someone else, with an optional warning message. Any user may clear all ownerships.
IxExplorer provides a further distinction of roles between users. Administrators are privileged users who may take ownership of ports, configure their characteristics, and initiate tests using those ports. Operators are unprivileged users who may only look at chassis, card, and port characteristics and measured data.
Note: We NEVER support multiple clients simultaneously changing data on one port. The rule is: one port-one owner for each system test. The ownership model should not be used to have one script take ownership of a port and another script take ownership of that same port with the same username because one client may be working with a copy of the port configuration that has been made invalid by another owner.
The two basic modes of multi-user operation are referred to as:
- Voluntary: All users are considered administrators and voluntarily login and take or clear ownership of ports. All chassis are initially configured in this mode.
- Secure: Users are characterized as Administrators or Operators. All users must login. Administrators operate in the same manner as all Voluntary mode users. Operators are restricted to viewing data.
Statistics Logging and Alerts
IxExplorer has the ability to centrally log statistics from any port and to signal alert conditions when a particular statistic goes out of a specified, valid range. The following figure shows the basic operation of logging and alerts.
Figure: Statistics Logging and Alerts

The clients (Client 1 and Client 2) run IxExplorer and are connected to all of the chassis (Chassis 1, Chassis 2 and Chassis 3) in the chassis chain. The clients set up conditions under which statistics data is logged and alerts generated. These conditions are transmitted to all of the chassis. Each chassis interprets these conditions and logs statistics data and alert conditions to their local disks.
When a chassis detects an alert condition, it sends signals to all of the clients connected to the chassis at the moment. Each client receives alerts from all of the chassis, regardless of whether they set up the particular alert condition themselves.
It can take considerable effort to set up one port's statistics logging and alert conditions. It is not necessary to repeat this process for multiple ports that have identical logging and alert behavior. IxExplorer's Port Copy feature may be used to copy these specifications.
It should be noted that logging and alerts continue even after a client has exited IxExplorer.
Statistics Logging
Each client selects particular statistics on particular ports to be logged. The data is logged at the chassis hosting the port. All clients connected to a chassis contribute their desired port-statistics to be logged. All statistics from all clients are logged to the same single file on a chassis.
The log file is ASCII in format and contains a line of text for each port on which statistics have been gathered. Each line contains all of the selected statistics for the port, separated by commas. The contents of the file are easiest to understand and interpret if the same statistics are gathered for all ports.
The statistic values that are logged are the `rolling average' for the value logged. That is, a value at time slot n depends on the previous average and the current measured value, as per the following equation:
Averagen = (Averagen-1 * (n-1)/n) + (Measurementn * 1/n)
The client specifies several parameters that affect the logging of statistics:
- Enable/Disable: Enable or disable all statistics logging specified from this client.
- Log at interval: Specify an interval between logged entries.
- Log during alerts: Log statistics while alert conditions exist.
- File naming: The format and location of logging files on the chassis.
Multiple clients should agree on the log interval and file naming conventions; the chassis uses the settings received from any client that applies changes.
Alerts
Each client sets up anticipated valid ranges for particular statistics on specific ports. All clients connected to a chassis distribute their specific valid ranges to all chassis. Each chassis watches for out of range values on the specified port-statistics and generates alerts for the conditions. All alert conditions are sent to all connected clients. Alert condition changes may be optionally logged on files at the chassis.
The client indicates how it wants to receive alerts for a particular statistic and port. There are three options:
- Visual: each statistic subject to alerting is displayed as green (in range), red (out of range) or yellow (was previously out of range) in any Statistic View containing the port-statistic.
- Audible: while any out of range condition exists, the client's computer issues a repeating beep-beep. A client may mute all audible alarms at once.
- Both visual and audible.
In addition, the existence of an alert condition for a particular port-statistic may be used to initiate statistics logging for that port, as described in Statistics Logging.
The client specifies several parameters that affect the setup of alert conditions:
- Enable/Disable alerts: Enable or disable all visual and/or audible alerts specified from this client.
- Enable/Disable Alert Logging: Enable or disable the logging of alert change conditions on the chassis.
- File Naming: The format and location of alert files on the chassis.
Multiple clients should agree on the valid range of port-statistics values and file naming conventions; the chassis uses the settings received from any client that applies changes.