Welcome to the Xena help information
This provides an overview of the features of the Ethernet testers from Xena Networks, primarily using the XenaManager application.
Introduction to the Xena products.
Overview... the XenaCompact chassis
Overview... the XenaBay chassis
Overview... the XenaManager application
Overview... connecting to a chassis
Overview... reservation
Overview... streams
Overview... statistics
Released: 3-08-2011, GA3
Copyright (c) 2008-2011 Xena Networks
Introduction to the Xena products
The XenaCompact and XenaBay testers are self contained network appliances that allow you to generate and analyze Ethernet traffic at wire speeds up to 100 Gbps. The testers are simple to use, powerful, and scalable. The applications are wide-ranging, from debugging newly developed hardware in a laboratory, to analyzing real live networks with multiple points-of-presence across the globe.
The testers come with different kinds of modules with different number of test ports and supporting different physical Ethernet interfaces:
M1CFP100, one 100 Gbps port using pluggable CFP transceivers, also supporting 40 Gbps and 10 Gbps.
M2CFP40, two 40 Gbps port using pluggable CFP transceivers, also supporting 10 Gbps.
M6SFP+, six 10 Gbps ports using pluggable SFP+ transceivers.
M2XFP, two 10 Gbps ports using pluggable XFP transceivers.
M2SFP+, two 10 Gbps ports using pluggable SFP+ transceivers.
M2CX4, two 10 Gbps ports using the CX4 electrical interface.
M6SFP, six 1 Gbps ports using pluggable SFP transceivers, electrical or optical.
Each XenaCompact tester has one module, while a XenaBay tester has up to 12 modules in any combination.
Hardware
This figure shows a XenaCompact tester whose module contains two 10 Gbps ports on the right; there are also two normal RJ45 Ethernet ports inside the orange front plate:
The left-most RJ45 port inside the orange plate is called the management port. It should be connected to a normal LAN supporting an IP network, and is used to configure and operate the tester.
The two test ports on the right use the SFP+ interface, which supports pluggable transceivers using different optical wavelengths. These ports are connected to the device-under-test or the network-under-test.
Software
The tester is controlled using the XenaManager application which runs on a normal Windows PC. It communicates with the tester through an IP connection to the management port. The Manager supports a straight-forward point-and-click interface to the tester, allowing you to configure test traffic and see the results.
This figure shows the XenaManager, with a navigation area on the left side, and two panels used for traffic generation on the right side:
Back to start
Overview... the XenaCompact chassis
XenaCompact comprises a range of 1U rack-mountable Ethernet test appliances.
Each XenaCompact chassis contains one horizontally mounted Xena test module which contains a number of test ports of a particular physical interface type:
C1-M1CFP100, containing an M1CFP100 module supporting one 40/100 Gbps pluggable CFP transceiver.
C1-M2CFP40, containing an M2CFP40 module supporting one 40 Gbps pluggable CFP transceiver.
C1-M6SFP+, containing an M6SFP+ module supporting six 10 Gbps pluggable SFP+ transceivers.
C1-M2XFP, containing an M2XFP module supporting two 10 Gbps pluggable XFP transceivers.
C1-M2SFP+, containing an M2SFP+ module supporting two 10 Gbps pluggable SFP+ transceivers.
C1-M2CX4, containing an M2CX4 module supporting two 10 Gbps electrical CX4 interfaces.
C1-M6SFP, containing an M6SFP module supporting six 1 Gbps pluggable SFP transceivers.
XenaCompact chassis are entirely front-operated except for the power cord which is attached at the back.
On the left side of the front panel are several LED indicators and the power switch:
Network activity LED, showing whether the management port is connected and active, normally on.
Disk activity LED, showing whether the internal disk is active, primarily on during start-up.
Power LED, showing whether power is attached and switched on.
The power switch turns power on and off with a quick press. Power can also be removed from the external attachment without any ill consequences. When power is applied the chassis starts up automatically without the need to press the power switch.
After turning the chassis on it takes 2-3 minutes to start up. When it is ready all the LEDs of the test module start flashing until the first connection is made to the chassis.
Before turning off power you must save any work in progress to a local PC using the XenaManager application. When the chassis is powered on it comes up in a well-defined and fully reset state.
The management interface
The test ports
Saving and loading
Back to start
Overview... XenaCompact test ports
On the right side of the front panel of the XenaCompact chassis is the test module with its ports. Each test port has a green LED indicating whether the port has achieved basic Ethernet sync with the port it is connected to. Most ports also have a yellow LED indicating that the port is transmitting packets.
The test ports are numbered consecutively, starting from 0 for the left-most port.
For information about the port interface types please see the appropriate test module section.
Back to XenaCompact
Overview... XenaCompact management interface
In the middle of the front panel of the XenaCompact chassis is an orange plate with a hole on the right exposing two RJ45 Ethernet ports.
The left of these RJ45 ports is called the management port, and the right is called the extension port. The management port is used by client applications to connect to the chassis using its IP address.
The orange plate can be removed, exposing ports for attaching a screen, keyboard, and mouse. This is for custom modifications to the tester and is not needed for normal operation.
IP address
Connecting
Back to XenaCompact
Overview... the XenaBay chassis
XenaBay is 4U rack-mountable Ethernet test appliance chassis.
It can contain up to twelve vertically mounted Xena test modules, each of which contains a number of test ports of a particular physical interface type:
The M1CFP100 module, supporting one 40/100 Gbps pluggable CFP transceiver.
The M2CFP40 module, supporting one 40 Gbps pluggable CFP transceiver.
The M6SFP+ module, supporting six 10 Gbps pluggable SFP+ transceivers.
The M2XFP module supporting two 10 Gbps pluggable XFP transceivers.
The M2SFP+ module supporting two 10 Gbps pluggable SFP+ transceivers.
The M2CX4 module supporting two 10 Gbps electrical CX4 interfaces.
The M6SFP module supporting six 1 Gbps pluggable SFP transceivers.
The XenaBay chassis is entirely front-operated except for the power cord which is attached at the back, and the main power switch which is located next to the power connector.
On the left side of the front panel is an orange plate attached to a black lid which can be removed to reveal a secondary power switch which turns power on and off with a quick press. Power can also be removed from the external attachment or at the main power switch on the back without any ill consequences.
After turning the chassis on it takes several minutes to start up, the longer the more modules are installed. When it is ready all the LEDs of all the test modules start flashing in a sweeping pattern until the first connection is made to the chassis.
Before turning off power you must save any work in progress to a local PC using the XenaManager application. When the chassis is powered on it comes up in a well-defined and fully reset state.
In the upper-right corner of the front panel are two LED indicators:
Power LED, showing whether power is attached and switched on.
Disk activity LED, showing whether the internal disk is active, primarily on during start-up.
In order to install new test modules into the chassis you must first remove the top cover and then follow a series of steps detailed in a separate document.
The test module slots
The management interface
Saving and loading
Back to start
Overview... XenaBay test module slots
The main portion of the front panel of the XenaBay chassis contains the slots used for one or more test modules. The lid of the chassis needs to be removed in order to insert or remove test modules.
Test modules can be inserted in any combination, in arbitrary slots, and slots can be left empty.
The module slots are numbered consecutively, starting from 0 at the left slot. Empty slots are also counted, so each test module is given a fixed number determined by its slot position, regardless of whether any other slot is used.
For each test module, the test ports are numbered consecutively, starting from 0 for the top-most port.
Each test port has a green LED indicating whether the port has achieved basic Ethernet sync with the port it is connected to. Most ports also have a yellow LED indicating that the port is transmitting packets.
For information about the port interface types please see the appropriate test module section.
Back to XenaBay
Overview... XenaBay management interface
The two right-most slots of the XenaBay chassis are used for the chassis controller, which contains two RJ45 Ethernet ports.
The top of these RJ45 ports is called the management port, and the bottom one is called the extension port. The management port is used by client applications to connect to the chassis using its IP address.
The chassis controller also has ports for attaching a screen, keyboard, and mouse. This is for custom modifications to the tester and is not needed for normal operation.
IP address
Connecting
Back to XenaBay
Overview... the IP address of a chassis
The RJ45 management port on the front panel of a chassis is used by clients to control the tester either using the XenaManager application or using scripting. It is given an IP address and should be attached to a network that makes it accessible to the client applications.
The management port is pre-configured with this IP configuration:
IP address: 192.168.1.200
IP subnet: 255.255.255.0
IP gateway: 192.168.1.1
The IP configuration can be changed using the XenaManager to suit the local network environment.
Connecting to a chassis
Back to start
Overview... the M1CFP100 module
The M1CFP100 test module has one 100 Gbps port, one or two 40 Gbps ports, or up to eight 10 Gbps ports, using pluggable transceivers of the CFP interface type.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis. In XenaBay it takes up two slots, so there can at most be six of these modules in a single chassis.
CFP transceivers come with a variety of optical interfaces, supporting different wavelengths, different modes of fiber, and different power output.
Some CFP transceivers support two 40 Gbps ports within a single transceiver. It is also possible to use external splitter cables or cartridges to obtain 40 Gbps ports or 10 Gbps ports from a 100 Gbps CFP transceiver. The test module mode needs to be configured accordingly in the XenaManager.
Please consult the specifications of your particular transceiver and fiber cable to ensure that a proper connection can be established.
The green LED indicator of the port is turned on when a fiber cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC". The yellow LED indicator is turned on when the port is transmitting packets.
There are only two sets of LED indicators, and there are no sync/traffic indications when in 10 Gbps mode.
Transceivers are hot pluggable, and can be removed and inserted while the tester is running.
Back to start
Overview... the M2CFP40 module
The M2CFP40 test module has one or two 40 Gbps ports, or up to eight 10 Gbps ports, using pluggable transceivers of the CFP interface type.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis. In XenaBay it takes up two slots, so there can at most be six of these modules in a single chassis.
CFP transceivers come with a variety of optical interfaces, supporting different wavelengths, different modes of fiber, and different power output.
Some CFP transceivers support two 40 Gbps ports within a single transceiver. It is also possible to use external splitter cables or cartridges to obtain 10 Gbps ports from a 40 Gbps CFP transceiver. The test module mode needs to be configured accordingly in the XenaManager.
Please consult the specifications of your particular transceiver and fiber cable to ensure that a proper connection can be established.
The green LED indicator of the port is turned on when a fiber cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC". The yellow LED indicator is turned on when the port is transmitting packets.
There are only two sets of LED indicators, and there are no sync/traffic indications when in 10 Gbps mode.
Transceivers are hot pluggable, and can be removed and inserted while the tester is running.
Back to start
Overview... the M6SFP+ module
The M6SFP+ test module has six 10 Gbps ports supporting pluggable transceivers using the SFP+ interface type.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis.
SFP+ transceivers come with a variety of optical interfaces, supporting different wavelengths, different modes of fiber, and different power output.
Please consult the specifications of your particular transceiver and fiber cable to ensure that a proper connection can be established.
The green LED indicator of the port is turned on when a fiber cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC". The yellow LED indicator is turned on when the port is transmitting packets.
The six port cages can have transceivers of different type or can be empty.
Transceivers are hot pluggable, and can be removed and inserted while the tester is running.
Back to start
Overview... the M2XFP module
The M2XFP test module has two 10 Gbps ports supporting pluggable transceivers using the XFP interface type.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis.
XFP transceivers come with a variety of optical interfaces, supporting different wavelengths, different modes of fiber, and different power output.
Please consult the specifications of your particular transceiver and fiber cable to ensure that a proper connection can be established.
The LED indicator of the port is turned on when a fiber cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC".
The two port cages can have transceivers of different type or can be empty.
Transceivers are hot pluggable, and can be removed and inserted while the tester is running.
Back to start
Overview... the M2SFP+ module
The M2SFP+ test module has two 10 Gbps ports supporting pluggable transceivers using the SFP+ interface type.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis.
SFP+ transceivers come with a variety of optical interfaces, supporting different wavelengths, different modes of fiber, and different power output.
Please consult the specifications of your particular transceiver and fiber cable to ensure that a proper connection can be established.
The LED indicator of the port is turned on when a fiber cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC".
The two port cages can have transceivers of different type or can be empty.
Transceivers are hot pluggable, and can be removed and inserted while the tester is running.
Back to start
Overview... the M2CX4 module
The M2CX4 test module has two 10 Gbps ports supporting the electrical CX4 interface.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis.
The LED indicator of the port is turned on when an electrical cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC".
Back to start
Overview... the M6SFP module
The M6SFP test module has six 1 Gbps ports supporting pluggable transceivers using the SFP interface type.
It is either the sole module of a XenaCompact chassis, or one of several modules of a XenaBay chassis.
SFP transceivers come with a variety of electrical and optical interfaces, supporting different port speeds, different wavelengths, different modes of fiber, and different power output.
Please consult the specifications of your particular transceiver and cable to ensure that a proper connection can be established.
One particular transceiver type is a triple-speed electrical 10/100/1000 Mbps interface using an RJ45 connector. This interface type support auto-negotiation of link speed and is the typical interface used on local area networks.
The LED indicator of the port is turned on when a cable is attached to a matching port of the system under test. Likewise, the XenaManager will show the port as being "IN-SYNC".
The six port cages can have transceivers of any mixture of types or can be empty.
Transceivers are hot pluggable, and can be removed and inserted while the tester is running.
Back to start
Overview... the XenaManager application
The XenaManager is the primary tool for controlling the XenaCompact and XenaBay testers. The other principal way of controlling the testers is through scripting, for instance using Tcl or through a variety of Microsoft Excel based applications.
XenaManager is a program running on an ordinary PC under Windows XP, Vista, or Windows 7. It is a stand-alone executable, to be run directly without requiring any installation.
This picture shows the basic layout of the XenaManager graphical user interface:
The XenaManager connects to one or more testers using their IP addresses, and provides a comprehensive point-and-click user interface for configuring and running the testers.
Connecting to a chassis
The navigation area
The content area
Entering values
Hexadecimal input
When input is disabled
Pulling out panels
Working with testbeds
Reconnecting
IP addresses
Scripting
Back to start
Overview... connecting to a chassis from the XenaManager
You connect to a chassis from the XenaManager by adding it to a testbed:
This prompts you for the IP address and password:
If the password is lost
The default value of the password is "xena", which can be changed from the "CHASSIS PROPERTIES" panel of the XenaManager.
If the password is forgotten the following method can be used to gain access to the chassis: after power-on when the test port LEDs start flashing, for the next two minutes the chassis will accept its own serial number (which is printed on the label at the back of the chassis) as a backup password.
If the IP address is lost
The extension port is not used in normal operation. It serves as a backup with a known IP address (172.16.255.200) if the address of the management port is lost.
IP address
Testbeds and the navigation area
Working with testbeds
Reconnecting
Back to XenaManager
Overview... testbeds and the navigation area of the XenaManager
The same instance of the XenaManager can control any number of testers, at any number of geographical locations, with any combination of chassis types, module types, and port types, collectively called resources.
Only a subset of the available ports of each tester may be relevant to a particular test application. The actual collection of testers and test ports is called a testbed. The XenaManager supports multiple testbeds for working on different projects, but only one testbed is opened at a time.
Note that a testbed is just a designated list of ports, and in itself does not carry any configuration of those ports. The actual configuration of all the ports in a testbed is called a test case. There will typically be many test cases for a particular testbed.
On the left side in the XenaManager is the navigation area which shows the testbeds and the collection of resources belonging to the currently open testbed:
You can left-click the resources to select them, or right-click on them to bring up a menu.
There is an alternative graphical view of the resources of the current testbed, shown if you select the "Testbed view" tab above the navigation area:
This is fully equivalent to the "Testbed explorer", and you can left-click and right-click the chassis, modules, and test ports in the same way.
Working with testbeds
Test cases
Back to XenaManager
Overview... content area of the XenaManager
On the right side in the XenaManager is the content area which shows detailed information about the currently selected resource from the navigation area. The information in the content area is organized into a number of tabs along the top:
The "Properties" tab applies to both chassis, modules, and ports, whereas most of the other tabs apply only to port resources.
For each tab there are one or more panels inside the content area:
You view and update the configuration of the tester through the parameter values shown in the various panels.
The panels that belong to the transmit side of a port are in light blue color, whereas those belonging to the receive side are in light brown color.
The top portion or a panel is called the title. The resource to which the panel belongs is shown on the left side of the title, like "Dev 1G / Module 0 / Port 2 / Stream 0". The type of the panel is shown at the right side, like "STREAM DEFINITION".
The panels can be collapsed and expanded by clicking their title. Inside the panels there may be sub-sections, like "Transmission profile", and they are also expanded and collapsed by clicking on their title.
In general you delete items from the various panels by clicking the little "X" buttons:
Entering values
Back to XenaManager
Overview... entering values in the XenaManager
You setup the tester configuration using the XenaManager simply by entering and modifying the values shown in the input fields of the various panels in the right-side content area:
While editing there is a vertical 'caret' and the value is shown in green color.
If the value has a wrong syntax or is out of range it is shown in red color:
You can press the <ESCAPE> key to revert to the previous value.
When you click away to another field, or press the <TAB> or <ENTER> key, the value is submitted to the tester. When validated the value is shown in the normal blue color:
Some input fields are allowed to be empty, indicating that the relevant feature is disabled:
Hexadecimal input
When input is disabled
Content area
Back to XenaManager
Overview... hexadecimal input in the XenaManager
Hexadecimal input fields in the XenaManager work slightly differently from normal input. Different portions of the field may be shaded to highlight the sub-field structure, input is always in 'over-write' mode, and the cursor is a block:
Otherwise hex input works as normal input: green while editing, blue when accepted, <ESC> to undo.
Back to entering values
Overview... when input is disabled in the XenaManager
If an input field in the XenaManager is shown using a gray background you cannot change its value:
There are various reasons for this:
The port is not reserved to you. Go to the "Properties" tab, and click the "Reserve" button.
Traffic is on. Go to the "Streams" tab, and click the "Stop traffic" button. When traffic is started you cannot modify any of the parameters that affect the generated traffic. In particular you cannot change the definition of any stream that is enabled, but you can edit streams that are not enabled.
Capture is on. While capturing is enabled the trigger and keep criteria cannot be changed.
Histogram is on. While a histogram is counting you cannot change the source or range.
Filter is active. While enabled you cannot change the filter condition or any of the terms used by it. You cannot delete a term that is used by any filter, nor delete a filter that is used for capturing.
There are various local dependencies that are typically fairly obvious, such as: in the "Packet content" sub-section of the "STREAM DEFINITION" panel you cannot edit the payload pattern while you have selected an incrementing payload.
Finally, the connection to the chassis may have been lost, and you'll have to reconnect.
Reservation
Streams
Capturing
Histograms
Filters
Reconnecting
Back to entering values
Overview... pulling out panels in the XenaManager
In practical use of the XenaManager you will do a lot of clicking on the resources of the navigation area and on the tabs of the content area, as you configure and inspect the various parts of your testbed.
For convenience you may pull out panels of the content area into their own little windows which remain open as you navigate to other resources or tabs:
This is done by left-clicking and dragging the title bar of the panel and dropping it somewhere on your screen. The panel retains full functionality and you can use it just as when it was nested inside the main window.
The original panel in the content area is replaced by a small remnant with an "X" at the left side. You close the pulled-out window and bring it back to the content area by clicking this "X". You can also just close the pulled-out window itself.
Global control
Back to XenaManager
Overview... working with testbeds in the XenaManager
A testbed of the XenaManager contains all the chassis which have ports that are relevant to a particular project. And if a chassis is not needed there is no reason to add it to the testbed.
However, different ports of a chassis may be used for different projects. So some of the ports of a chassis may in fact not belong in the testbed, and should be excluded from view.
Using ports
Whether a port is used by the current testbed is controlled by right-clicking on the port:
Ports that are not used by the current testbed are shown using italic font in the navigation area.
It is also possible to completely suppress the display of un-used ports:
You will typically do this once you have built your testbed and selected the ports that belong to it, leaving you with a neat view of the relevant resources.
Of course, if you need to bring an un-used port into the testbed you need to first make sure all the ports are shown in order to be able to right-click it.
Export and import
The contents of each testbed are retained locally by the XenaManager, and all testbeds are available in the testbed explorer as soon as the XenaManager application is started.
If you want to back-up a testbed, or share it between different users, you can export it by right-clicking the testbed name:
Note that the testbed has to be closed before it can be exported.
The file can then be used to import the testbed into the XenaManager on a different PC:
Testbeds
Test cases
Back to XenaManager
Overview... reconnecting from the XenaManager
The connection to the chassis can get lost, typically because of network problems or because the chassis has been powered down. With the XenaManager you can see the status in the "CHASSIS PROPERTIES" panel:
The chassis name will also be shown using italic font in the navigation area.
In this situation the XenaManager retains the last known value for each parameter, but nothing can be changed. You can try and reconnect using the right-click menu of the chassis:
If the reconnect is successful the XenaManager pulls in a complete fresh set of values from the tester. Everything can have changed, since the tester may have been powered down and the modules changed, or this may simply be a different Xena tester using this IP address.
Connecting
Navigation area
Back to XenaManager
Overview... tester state
The Xena testers keep operating and retain their own state regardless of whether there are any clients connected to them. You can connect using the XenaManager or scripting, start some traffic, disconnect from the tester, and connect again later to see how the traffic is doing.
After being powered on or restarted all the test port configurations are in a fully reset state, with no streams defined, no filters, no capturing, etc.
As clients connect they can reserve the ports and then change the port configurations, start and stop traffic, capture received packets, etc. And this state is retained on the tester even as the clients disconnect.
In general, connecting with the XenaManager or starting a scripting session has no impact on the state of the tester. They simply see the tester in its current state. If that state changes due to other users it may need to be refreshed.
Connecting
Reservation
Refreshing
Saving and loading
Back to start
Overview... refreshing the state in the XenaManager
While the XenaManager is connected, a port may be reserved by another user who changes the port configuration. The values shown by the XenaManager may then be out-of-date, and can be refreshed using the right-click menu of the port in the navigation area:
The entire tester can be refreshed using the right-click menu of the chassis.
Note that the statistics are automatically refreshed every second.
Statistics
Back to tester state
Overview... saving and loading
Using the XenaManager, the full configuration for a port can be saved to a file on the client, using the right-click menu of the port:
Likewise, once a port is reserved, a configuration can be loaded from a file on the client, again using the right-click menu of the port.
Loading a configuration that was saved from a different port has the potential to create MAC address conflicts or test payload conflicts. The XenaManager will provide a few prompts allowing you to resolve this.
To establish a well-known state for a port, the client should connect to the tester, reserve the port, and load a particular configuration for it from a file on the client.
When the tester is powered down or restarted all port configurations are lost. Any work in progress should therefore be saved first.
Configurations for multiple ports can be saved in a single operation using the XenaManager's concept of a test case.
Reservation
Tester state
Port configuration files
Test cases
Back to tester state
Overview... reservation
The Xena testers support multiple simultaneous connections from any mixture of clients, whether using the XenaManager or scripting.
As soon as a connection has provided the password for the chassis any port of the tester can be inspected.
But in order to configure ports they must first be reserved. The same applies to changing the configuration of the chassis itself and its modules: they must first be reserved. At most one client connection can have a particular resource reserved:
Reserved ports are shown using bold-face in the left-side navigation area.
Before making reservations you must specify a user name. Then you can either reserve, release, or relinquish ports.
User names
The Reserve-Release-Relinquish button
Connecting
Navigation area
Back to start
Overview... user names
Before reserving resources, the client must identify itself with a user name.
In the XenaManager this is done from the "Manager -> User name..." menu:
User names are short self-chosen strings, typically just the initials of the user. The XenaManager retains the name across invocations so you do not need to type it in every time you start the XenaManager application.
The name is simply used to tag the reserved resource, and the testers have no notion of actual 'user accounts'. Multiple connections could use the same name, but any resource will only be reserved to one connection at a time.
Back to reservation
Overview... the Reserve-Release-Relinquish button
Using the XenaManager you reserve a port by selecting it in the left-side navigation area, selecting the "Properties" tab in the content area, and clicking the "Reserve" button on the "PORT PROPERTIES" panel:
Once reserved, your user name is now shown as the owner of the port. Also note that all the input fields become active. The configuration of the port can be freely updated, traffic can be started and stopped, packets captured, etc.
When the port is no longer needed it can be released by pressing the same button as before which is now called "Release":
The port will now be shown as free again, and the input fields are grayed out since no new values can be entered.
Note that if you disconnect from the tester while having ports reserved, that reservation state is maintained just like any other tester state, and others cannot use the port even while you are disconnected. When you connect the next time you will inherit the reserved state and can change the configuration right away.
If you encounter a port that is reserved to someone else, that user's name is shown in red color and the button is called "Relinquish":
You can take the port away from the current owner by pressing this button, and then optionally reserve it to yourself. You will be prompted for confirmation, but otherwise there is no barrier to freeing the port. This model supports a cooperative mode of sharing the tester resources between different users.
Finally, when the testbed has many ports and they all need to be reserved, for instance to load a test case, you can use the top-level menu to reserve all the ports of the current testbed:
User name
Entering values
Tester state
Testbed
Test cases
Back to reservation
Overview... scripting
As an alternative to using the XenaManager, you can interact with the testers using a command-line interface. This also allows the tester to be controlled from a scripting environment, and be part of a larger automation environment.
Everything that can be done using the XenaManager can also be done through scripting, and in a nearly identical fashion. Please keep this in mind even though most of the examples use the XenaManager for illustration.
The commands are simple lines of text exchanged between a client and the Xena chassis. An example command to the chassis could be:
0/5 PS_RATEPPS [3] 500000
This goes to module 0, port 5, and sets stream 3's rate to 500000 packets per second. The chassis responds with:
<OK>
You would query for the current value this way:
0/5 PS_RATEPPS [3] ?
And the chassis would respond in exactly the same way that you set the value yourself:
0/5 PS_RATEPPS [3] 500000
Note that this is exactly the same syntax used when saving and loading port configurations to files on the client PC. This allows you to use saved configurations as a starting point for scripting, and it also allows you to modify the saved files before loading them back into the chassis.
The full syntax of all the scriptable parameters is defined in a separate document available from the Xena Networks web-site, http://www.xenanetworks.com/html/resources.html.
The scripting mechanism is the basis for various Microsoft Excel based applications provided by Xena Networks, and can be exploited in the same way by any user, for instance using Tcl.
Making a script connection
Port configuration files
Test cases
Back to start
Overview... making a script connection
The chassis support multiple concurrent scripting sessions, just like they support multiple concurrent interactive XenaManager sessions. And likewise, scripting sessions interact with the chassis in its current state. Establishing a scripting session does not in itself impact the chassis state.
In order to start a scripting session you establish a TCP/IP connection with the chassis using port 22611, on the same IP address as when using the XenaManager.
You then send lines of ASCII text to the chassis, terminated by CR/LF, and receive lines of ASCII text in response. The first command should be a logon with the valid password for the chassis, or the session will be terminated.
You can use any client platform that is able to establish a TCP/IP connection and send and receive lines of text through it. Typical client platforms include Tcl, Perl, Python, Java, Excel/VBA, and Telnet. You may use client-side functionality to execute script commands conditionally and repetitively.
Note that the notion of a multi-chassis testbed is created by the XenaManager, and is not defined at the scripting level. Each script connection to a chassis is independent of other connections, and any inter-chassis functionality must be implemented in the client environment.
Xena provides a simple interactive scripting client application that runs on Windows. It is similar to telnet and allows you to manually type commands to the chassis and see its responses:
Typing "HELP ?" explains how to get a compact overview of the available commands.
Tester state
Back to scripting
Overview... RFC 2544
Xena provides a script-based implementation of the RFC 2544 test suite framework, which performs four kinds of tests for a range of packet rates and packet lengths across a collection of ports.
It uses Microsoft Excel as the scripting platform and Visual Basic as the scripting language. Hence it is just a collection of spreadsheets inside a single Excel workbook:
You use it by filling in various cells with a light-gray background and clicking on some buttons on the spreadsheets.
On the "Connect" sheet you first enter the IP address of the chassis to use for the test, and which ports to use:
You then click the "CONNECT" button, which reserves the ports and downloads some port-level property values that you can modify if needed.
You then proceed through a few more sheets to fully define the test scenario, for instance setting the rate/size parameters on the "TestCfg" sheet:
As you run each of the THROUGHPUT, LOSS, LATENCY, and BACK-TO-BACK tests, they will provide detailed results for each test case:
Once the tests are concluded, a numerical summary is provided on the "Reports" sheet, and a grahical summary as well on the "Charts" sheet:
The spreadsheets can be customized at will, for instance by adding more extensive reporting using all the available features of Excel. The script code can also be inspected and modified.
Back to start
Overview... properties
Ports, modules, and the chassis itself have various settings and information, which you access under the "Properties" tab in the content area of the XenaManager after clicking on the appropriate resource in the navigation area.
The most commonly used are port properties:
On the left you have the reservation button, and on the right you have some basic information about the port such as its speed and interface type.
There is a section with settings relevant for Layer-2, the Ethernet layer itself:
The minimum inter frame gap specifies how tightly packets are spaced at 100% load. Note, that this also includes the Ethernet 'preamble' - the inter frame gap is considered to be all the space between the end of one packet and the beginning of the next one.
The MAC address is a 6-byte Ethernet address that is used by default as the source address of outgoing packets.
MAC training means that the port will periodically send packets even when traffic generation is off, to announce its MAC address to the nearest switch.
The port can be configured to react to incoming PAUSE frames, which will then cause a brief suspension of outgoing packets.
There is a section with settings relevant for Layer-3, the IP protocol layer:
You can specify a set of IPv4 address parameters, which are used by default as the source address of outgoing IPv4 packets, and also when using ARP to set the destination MAC address of a packet header.
You can select whether the port itself should respond to incoming ARP and PING requests. You can use wildcards on each IPv4 address component, and thereby simulate the presence of a whole range of IPv4 nodes.
Finally, there is a section with various port-level functions:
The loop modes include:
RX-to-TX: incoming packets are sent back out from the port, and internal traffic generation is ignored. This makes the test port loop external traffic and still be able to analyze it.
TX-to-RX: outgoing packets are sent back into the port, and received external traffic is ignored. This is an internal traffic loop and is useful for debugging stream configurations.
Port-to-port: like RX-to-TX but for pairs of ports like 0+1, incoming packets from each port are sent back out on the other. This allows you to put the tester in-line on a link and intercept and analyze the traffic.
There is a latency offset, which is subtracted from the absolute latency measurements for the port.
The gap monitor makes the port look for any interruptions in a steady train of incoming packets:
Start, specifies the maximum number of microseconds allowed between packets before starting a gap event.
Stop, specifies how many packets below the start threshold are required to terminate a gap event.
The gap statistics are displayed on the "RECEIVE STATISTICS" panel, and gap events can be logged on the "RECEIVE LOG".
You can enable a special payload checksum that covers all the bytes of the packet after the Ethernet header. With this, a payload error will be declared even for modifications inside the header, including time-to-live changes.
Some parts of the traffic generation uses pseudo-random values to vary the packet lengths, modifiers, etc. You can specify an explicit seed value that makes the values reproducible each time you start traffic generation, which can help debugging.
Streams
Packet length
Packet header
Packet modifiers
Statistics
Latency diagnostics
Event logging
Back to start
Overview... streams, traffic generation
Streams are the basic mechanism for generating outgoing traffic to be transmitted on the test ports. Each port supports multiple stream definitions which can be configured independently of each other.
Streams are defined under their own "Streams" tab in the content area of the XenaManager, which is also where you control whether traffic generation is on..
Traffic generation is explicitly started and stopped for each port:
Once traffic is started, all the enabled streams contribute packets to the port.
A stream definition consists of two main parts: the transmission profile which specifies how the packets should be spaced in time, and the packet content which specifies the actual data bytes comprising each packet.
Transmission profile:
Rate
Burstiness
Enabling, suppressing and capping
Packet content:
Structure
Length
Header
Modifiers
Payload
Test payloads
Global control
Back to start
Overview... transmission rate
The most important parameter for a stream's transmission profile is the rate, which specifies how much of the bandwidth available for the port is consumed by the stream.
The rate can be specified in three different ways:
Percent, which is the fraction of the underlying bandwidth consumed, including the bandwidth used for the minimum inter packet gap required between packets.
Packets per second, where the amount of bandwidth consumed depends largely on the average length of the packets defined for the stream.
Mega-bits per second, which is the amount of bits transmitted at layer-2, hence excluding the bandwidth used for inter packet gaps.
This picture shows some rates for a stream of 80-byte packets with an inter packet gap of 20 bytes on a 10 Gbps port:
Whenever you specify a rate using one of these methods that rate becomes the primary rate. The corresponding rates for the two other methods are called derived rates.
In the XenaManager the primary rate is shown with the normal blue color, and the derived rates are shown with gray text color. You can still edit one of the derived rates, which then becomes the new primary rate.
The XenaManager automatically calculates derived rates. This also takes into account the packet length defined for the stream, and indeed if you change the packet length the derived rates will be re-calculated.
Packet lengths
Statistics
Back to streams
Overview... burstiness
By default the packets of a stream are spaced evenly in time.
The stream can be made bursty by reducing the gap between packets, and then increasing the gap between bursts to keep the rate unchanged.
This is accomplished by specifying the number of packets in each burst, and the burst density: a density of 100% means packets are transmitted back-to-back within the burst, whereas 0% means an even non-bursty spacing:
The XenaManager also calculates the spacing between packets within the burst and the spacing between bursts, and gives a simple illustration of the burst pattern.
The burstiness of a packet stream can be measured using the capture timestamps or using a histogram on the inter frame gap.
Capturing
Histograms
Back to streams
Overview... enabling, suppressing and capping streams
A stream needs to be enabled before it is included in the traffic generated for a port:
The sum of the rates defined for all enabled streams must not exceed the effective bandwidth of the port. The effective bandwidth of a port can itself be slightly reduced, in parts-per-million, by specifying a speed reduction parameter on the "PORT PROPERTIES" panel in the XenaManager.
When also counting non-enabled streams, the total rate is allowed to exceed the port rate, allowing you to maintain a collection of stream definitions that are enabled in various combinations. Even a single non-enabled stream rate can exceed 100%, which can be helpful while defining the streams and adjusting their rates.
But if an enabled stream would bring the total bandwidth consumption above 100% the rate needs to be capped. This can be done explicitly by pressing the "Cap" button in the XenaManager:
Capping will be automatically enforced when enabling a stream or when editing the rate of a stream that is already enabled.
Capping can also be applied to the packet length, if for example you try to increase the packet length of a stream whose rate is specified in packets-per-second (or by decreasing the packet length when the rate is specified in Mbps, because the relative inter packet overhead increases).
An enabled stream can be suppressed while traffic is generated for the port, stopping it from contributing outgoing packets. It can be re-enabled again, and these operations do not affect the packets contributed from any other streams for the port.
Streams can also be initially in the suppressed state when traffic generation for the port is started. Unlike disabled streams, suppressed streams use a part of the port's bandwidth, and are subject to capping just like enabled streams.
When changing port-level parameters that affect the overall bandwidth, like minimum inter frame gap on the "PORT PROPERTIES" panel, all streams are disabled, and you must re-enable them in whichever combination you choose.
Transmission rate
Packet lengths
Back to streams
Overview... packet structure
All packets of a stream generated and transmitted by the Xena testers have the following general format:
The first protocol segment of the header is the standard 6+6+2 byte Ethernet header. The last portion of the packet is likewise the standard 4-byte Frame Check-Sum.
Back to streams
Overview... packet lengths
The packets of a stream can be either of fixed length, or can be varied from packet-to-packet by various distributions between a minimum and a maximum length:
An incrementing distribution produces these lengths: Min, Min+1, Min+2, ..., Max-1, Max.
The butterfly distribution produces these lengths: Min, Max, Min+1. Max-1, Min+2, Max-2, ...., (Min + Max) / 2.
Both the incrementing, butterfly, and random distributions produce an average packet length of (Min + Max) / 2, and the butterfly distribution has the smallest deviation from this average over any short sequence of packets.
There is also a mixed distribution which approximates typical traffic on the Internet. Packet lengths vary between 56 - 1518 bytes, with an average length of 464 bytes.
The packet length has an impact on the amount of bandwidth consumed by the stream.
When the transmission rate is specified as packets-per-second then the bandwidth consumption is essentially proportional to the packet length. When using an Mbps rate the coupling is weaker, only impacted by the overhead from the inter packet gap.
Therefore the packet lengths are also subject to capping by the XenaManager if you exceed the available bandwidth.
Transmission rate
Enabling and capping
Back to streams
Overview... packet header
The header portion of the packets of a stream has a fixed size, which is partitioned into a number of protocol segments. In the XenaManager the header is created and edited using the packet editor which is simply a horizontal strip showing the list of protocol segments:
The name of each protocol segment is shown as a label along the top of the strip. The first protocol segment will always be the standard 6+6+2-byte Ethernet header.
Below each protocol label you can edit the raw byte content of this protocol segment in hexadecimal format. You can hide or show the hexadecimal boxes using the little arrows right of the protocol labels.
You can also click on the protocol label, which brings up a field-by-field display of the contents of this protocol segment. This allows you to view and edit the fields individually, in a way that in appropriate to their types:
You add and remove protocol segments by clicking the "Add" and "X" buttons in the right corner of the packet editor strip. Pressing "Add" gives you a choice of built-in protocols to choose from:
If you need to insert an un-supported protocol segment you can add a fixed-size custom segment by just specifying its length. You will then be able to view and edit this segment at the byte-by-byte level.
If you have added an IPv4 protocol segment, then there are buttons to send ARP and PING requests to the network in order to build and verify a proper packet header.
The combined length of all the protocol segments of the header is shown at the right end of the packet editor strip.
Hexadecimal input
Back to streams
Overview... packet modifiers
By default the content of the packet header is identical for every packet transmitted for a stream. The only part that (optionally) varies is the length.
To generate variation on a packet-by-packet basis you can add one or more modifiers to the packet header. In the XenaManager you do this by clicking the "Add field modifier" button:
The portion to be modified is specified by the byte-position from the start of the packet and a bit-mask. These values can be specified manually or you can click the label at the left to bring up the list of fields corresponding to the protocol segments defined for the header:
Once you have specified which portion of the header is to be modified, you specify how to modify it: incrementing, decrementing, or random variation.
The packet editor strip underlines the bytes that are affected by a modifier:
It uses a similar dashed underline for fields that are automatically modified by the hardware, in particular the IPv4 header's length and checksum fields:
By default the bits corresponding to the mask are run through all possible values. But for incrementing and decrementing modifiers you can specify explicit start, step, and stop values, by clicking the little arrow left of the label:
This section also allows you to specify a repeat count for the modifier. By default each packet that is generated for the stream will get a new value of the modified portion. With the repeat count you slow down the modifier so multiple packets will retain the same value before going to a new value.
When you have multiple modifiers this allows you to create a coupling between them so that together they sweep over a combined range of values. If the repeat count is left blank (corresponding to 1) the modifiers will run independently and each will change for every packet.
Packet header
Back to streams
Overview... packet payload
In the packets generated for a stream, after the header portion of a packet comes the payload portion, which absorbs any variation in the length of the packets.
The content of the payload portion is either a sequence of incrementing bytes or a fixed pattern of bytes that is repeated up through the packet:
You can also specify PRBS payload, which creates a continuously changing pattern from packet to packet.
Packet header
Packet lengths
Back to streams
Overview... test payloads
At the end of each packet generated for a stream is a special signature called a test payload. They are the key to distinguishing traffic streams at the receiving ports as well as performing integrity checks and timing measurements.
The test payloads contain various sequence numbers, time stamps, and checksums which are inserted automatically. They also contain a test payload identifier, or TID, which is chosen by the user and specified as part of the stream definition:
The test payloads belonging to each TID value are analyzed separately at the receiving port. In particular, the number of packets belonging to this TID are counted, and it is verified that the sequence numbers are unbroken.
Test payload identifiers should be assigned to be globally unique for every stream generated for every port of every chassis across the entire testbed. This is the easiest way to prevent any ambiguity at the receiving ports.
It is certainly invalid to use the same TID for more than one stream arriving at a particular port, since that port will assume they belong to a single stream and the sequence numbers will be jumbled.
However, it is perfectly valid to multi-cast or broad-cast a stream of packets containing test payloads: each receiving port will perform its own counting and checking of the received packets, and any weak path to a particular receiver can be detected and diagnosed.
Packet structure
Source ports
Error diagnostics
Latency diagnostics
Back to streams
Overview... filters and terms
Every port has a filter mechanism for inspecting all the received packets and recognizing particular patterns within the packets. Filters are defined under their own "Filters" tab in the content area of the XenaManager.
Filters are independent of the test payloads and provide an alternative method for analyzing the train of received packets.
Filters are logical expressions on a number of basic true-or-false terms, which can be of two types: match terms and length terms.
Match terms look for a particular pattern of bits at a particular position within each packet:
Like for modifiers, a match term will typically correspond to a particular protocol field.
And like for modifiers, in the XenaManager you can click the field label to specify the position and mask as a protocol field. However, since a filter is not related to any stream definition you need to manually click the "Add" button to build the needed protocol segments:
Length terms look for packets that are longer or shorter than a particular size:
Match terms are named M0, M1, M2, ... and length terms are named L0, L1, L2, ... These names are used when the terms are combined using a Boolean expression to form a filter condition:
The condition can use the usual Boolean operators &, |, and ~. As usual, the | operator has lowest precedence.
Any term can be used in any number of filter conditions for the port, so for instance a match term looking for a particular VLAN tag can be used in multiple conditions for packets using that tag.
Filters can be used in different ways: the port will accumulate separate statistics for packets satisfying the filter condition, the capture mechanism can use the filters as start/stop/keep criteria, and likewise for the histogram mechanism.
Test payloads
Modifiers
Capture
Histograms
Back to start
Overview... capturing packets
All packets arriving at a port are counted and analyzed if they contain test payloads. In addition, selected packets can be retained for closer inspection using the capture mechanism, which is accessed under its own "Capture" tab in the content area of the XenaManager.
Capturing is explicitly started and stopped, like traffic generation on the transmit side of the port:
Once started, the capture mechanism is based on three criteria: first an optional start trigger event needs to happen, then packets meeting a keep criteria are retained, until an optional stop trigger event happens:
Trigger events and keep criteria include detection of FCS-errored packets, a specified test payload TID value, or filter conditions.
When using a start trigger, capturing is automatically stopped if the hardware capture buffer runs full. When using only a stop trigger, the hardware capture buffer retains as many packets as possible up until the stop trigger event. The XenaManager provides a simple illustration of the start/stop trigger behavior.
Using the XenaManager the captured packets can be inspected using a horizontal packet viewer strip identical to the one used for building packet headers:
The header of each packet is inspected and decoded according to the protocols known to the XenaManager. The packets can also be exported to Wireshark for more comprehensive analysis.
You use the up and down arrows on the left to scroll the list of captured packets.
Each packet is tagged with the time it was captured relative to capture-start, and its actual length. The length is significant because only a portion of each packet may be retained in order to save space in the hardware capture buffer. If the packet contains a test payload then its latency is also calculated. You select which of these numbers to display using the drop-down box next to the scroll arrows.
The XenaManager also provides a more condensed graphical view of the length or spacing of the captured packets, as well as the latencies. Here is an example of a captured stream using the butterfly length distribution:
Traffic generation
Packet structure
Packet lengths
Packet headers
Test payloads
Latency diagnostics
Filters
Global control
Back to start
Overview... histograms, counting packets
Histograms analyze a stream of packets, either at the transmit side or the receive side of a port, and classify them into a number of buckets, counting how many packets go into each bucket.
Histograms complement the statistics, which just provide aggregate counts, and capturing, which provides per-individual-packet information.
Like transmitting and capturing, histograms are explicitly started and stopped:
A histogram is defined in terms of its source and its range.
The source specifies which packets should be analyzed and for which parameter, such as: transmitted packet length, received packet inter frame gap, received packet latency, etc.
Please note the difference between inter frame gap and latency: inter frame gap is the time elapsed since the previous packet was encountered, whereas latency is the time this packet itself has been in transit. Inter frame gap times are converted to the equivalent number of bytes, whereas latency is measured in nano-seconds.
The range specifies an offset and the bucket size, and thereby the resolution of the counted parameter:
Once a histogram is started, the XenaManager provides a graphical display of the counts:
All the buckets start off empty, and as packets are encountered (according to the source) they are counted (according to the range), and a picture emerges. Hovering the mouse over a particular vertical bar pops up a little window with the exact numbers for that bucket. The bucket counts can also be saved to a file for more detailed analysis.
With a partial picture you can click three zoom buttons to quickly adjust the range settings and restart the histogram:
You can also zoom in by dragging the mouse across a section of the histogram.
Traffic generation
Capturing
Statistics
Global control
Back to start
Overview... statistics, packet counts and rates
All traffic leaving and entering each test port is counted, and there are separate counts for a variety of different traffic classes: per port, per stream, per test payload, per filter, etc.
The basic statistics for each traffic class are:
Percentage, of the physical bandwidth
Mbits/sec, mega-bits in the last second
Packets/sec, packets in the last second
Bytes, accumulated number of bytes
Packets, accumulated number of packets
The numbers can be quite long, and a "," is used to separate the digits into groups of three. A "." is the decimal separator.
Whereas percentages are measured at layer-1, Mbits/sec and Bytes values are at layer-2. So they include only the useful portions of an Ethernet packet, from and including the destination MAC address up to and including the frame check sum, and exclude the preamble and any additional inter frame gap.
Observed Mbits/sec rates will therefore always be below the physical rate of the port which is specified at layer-1 and hence includes everything. For instance, with a packet length of 80 bytes and an inter frame gap of 20 bytes, 100% load on a 10 Gbps link will result in 8000 Mbps of traffic at layer-2.
In the XenaManager, the statistics are grouped into transmit statistics and receive statistics. Each group has some buttons:
"Mark", draws each current value in a faint color, making it easy to see when the value has changed.
"Clear", clears all counts to zero. This requires the port to be reserved.
"Save", saves the current values to a file, for instance for logging or post-processing purposes.
On the transmit side, there is a set of statistics for each stream generated by the port:
On the receive side, the central statistics concern the various test payloads that have been observed in the incoming packets. They are counted separately for each TID value:
The "Clean" button erases the list of observed TIDs. It is rebuilt as packets arrive with test payloads containing new TID values.
In addition to the traffic counters, there is a second section showing the error checks, and a third section showing latency measurements for each test payload stream. Some of these require the source port for the stream to be identified.
The receive side also has a section showing the traffic counts for each filter:
Transmission rate
Source ports
Error diagnostics
Latency diagnostics
Reservation
Streams
Global control
Back to start
Overview... source ports
The basic error checking mechanism needs only observe the test payloads in the incoming trains of packets; they could originate from any Xena tester anywhere in the network under test, possibly not even included in the current testbed.
But various other diagnostics require the XenaManager to know which port is generating the packets observed with a particular TID value, called the source port:
Since packets can take an unknown path through the system under test, determining the source port is based on a simple heuristic. The XenaManager looks at all the streams defined within the current testbed, and if there is exactly one stream using a particular TID value, then this is assumed to be the source of the packets observed at the receiver.
If no stream in the testbed uses the needed TID value then the source port is shown as "(unknown)". If there is more than one then it is shown as "(ambiguous)".
Testbeds
Error diagnostics
Latency diagnostics
Back to statistics
Overview... error diagnostics
The receive-side error check diagnostics, which are available for each received test payload TID value, comprise:
Lost packets, a running count based on gaps in the sequence numbers.
Mis-ordered packets, where a packet arrives later than one with a higher sequence number.
Payload errors, where the packet payload is not an unbroken sequence of incrementing bytes.
The error checks are based on test payloads, they are active while traffic is running, and they do not depend on knowing which port is sending the traffic.
The XenaManager also displays the overall error rate as a 1.2e-9 style number, calculated from the errors and the number of received bytes.
For missing packets there is also a simpler mechanism that simply compares the total number of packets transmitted and received for a particular stream. This requires knowing the source port.
When the source port stops transmitting, the packet counts will stop changing and any difference between the sent and received count is shown as "(TX - RX) packets".
Note that this requires that both transmit and receive statistics are cleared before traffic is started, or else it will show a non-factual loss. The statistics will automatically be cleared if you use the global "START" button.
Test payloads
Source ports
Global control
Back to statistics
Overview... latency diagnostics
Latency measurements are available for each received test payload TID value.
Latency measures the time-in-transit of a packet from transmitter to receiver. There are a variety of last/first-bit modes selectable on the "PORT PROPERTIES" panel. The source port and the receiving port are required to be in the same chassis.
The receiving port accumulates the average latency for all the packets belonging to a particular TID, and logs the minimum and maximum values:
It is also possible to obtain latencies for individual packets by using the capture mechanism.
The absolute values of the latency measurements are not truly indicative of latency in the system under test, because for instance the test module transceivers will add some latency of their own.
This can be compensated out by connecting a cable directly between the two ports, running some traffic, and pressing the "Calibrate" button. This redefines the minimum latency as zero, by setting the latency offset value which is part of the port-level properties.
Test payloads
Source ports
Capturing
Properties
Back to statistics
Overview... service disruptions
The receive logic can look for disruptions in an expected steady stream of incoming packets. This assumes that you have separately established a transmitting stream that sends a regular train of packets through the network under test to the receiving port.
Different kinds of service disruptions are defined, for different situations and time scales:
No-sync, which simply monitors whether the port has established RX sync. Such a disruption would typically be because of an unplugged cable or a reset of the equipment directly attached to the Xena test port.
Zero-rate, which monitors the port-level packet rate of incoming packets that is shown on the receive statistics, which is updated with a one-second period. Such a disruption would typically be because of an unplugged cable or a reset of the equipment deeper inside the network under test.
Gap monitor, which monitors the incoming packet stream for gaps in the milli/micro-second range, according to the parameters defined under port properties.
The number of service disruption events is displayed along with the accumulated duration of those events.
Note that the no-sync and zero-rate events are detected by the XenaManager and therefore require an active connection to the tester. In contrast the gap monitor events are detected by the tester hardware and are therefore accumulated regardless of any XenaManager connections and shared across them all.
Service disruption events can be time-stamped and logged by an active XenaManager.
Properties
Streams
Statistics
Event logging
Back to start
Overview... event logging
The transmit and receive statistics show momentary traffic rates and the accumulated traffic counts since statistics were last cleared. This also applies to the error statistics: they show the accumulated number of error events, without specifying when those events occurred.
The "RECEIVE LOG" panel complements the statistics with a time-stamped log of interesting events:
By default only IN-SYNC and NO-SYNC events for the port are logged. Checkboxes allow error events and service disruption events to be logged also.
The XenaManager queries the tester every two seconds, and if any of the tracked values have changed it generates an entry in the log. If events are frequent and this generates too much information, then a checkbox allows you to go to a one-minute logging interval.
Note that the tester itself does not record log information, so logging requires an active XenaManager connection to the tester. When the XenaManager is closed the log entries are lost, but they can be saved to a file.
Statistics
Error events
Service disruptions
Back to start
Overview... 40/100G configuration
The M1CFP100 and M2CFP40 test modules can provide port speeds of 10, 40, and 100 Gbps, subject to the module type, the transceiver type, and the external cabling. The number of ports can also vary, even for a single transceiver.
The test module itself is configured to the appropriate number and speed of the ports on the "MODULE PROPERTIES" panel:
Some CFP transceiver types (e.g. LR4) allow only a single port configuration, and they are called fixed. Others (e.g. SR10) allow individual fibers to be allocated in different combinations for multiple port speeds, and they are called flexible.
Once the CFP configuration is determined at the module level, the individual ports are configured and used in the normal way.
40/100G CAUI testing
40/100G PRBS testing
Streams
Statistics
Back to start
Overview... 40/100G CAUI testing
Ethernet at speeds of 40 and 100 Gbps uses the CAUI standard at Layer-1, the physical coding sub-layer. This divides the traffic into a number of physical lanes, which are transmitted together in various combinations depending on the interface type.
Within each lane the data is divided into 66-bit codewords which contain a 2-bit header. The data in each physical lane carries an alignment marker which contains the virtual lane number for this portion of the traffic.
Lanes may be physically swapped along the path from transmitter to receiver, and once the alignment markers are located inside each received lane the virtual lane numbers are used to put things in the right order.
The lanes may also get skewed in time relative to each other during transit, and the alignment markers are also used to do the required de-skewing in the receiver.
On the transmit side, you can manually swap and skew the lanes:
You can also inject different kinds of CAUI errors into specific lanes.
On the receive side, you can see whether there is proper header lock and alignment lock, and which virtual lane and actual skew is detected for each physical lane:
You can also see which kind of CAUI errors are detected in each lane.
40/100G configuration
40/100G PRBS testing
Back to start
Overview... 40/100G PRBS testing
The physical lanes of a 40 or 100 Gbps port can also be put into PRBS mode, where they transmit a pseudo-random bit pattern which can be useful for testing physical cabling and connectors.
On the transmit side, you select whether each lane should be in PRBS mode, and also whether it should be subject to error injection:
Errors can be injected individually by clicking a button, or continuously by specifying a rate. Error injection also works for lanes that are not in PRBS mode, and can thus be used to simulate bit-level errors into the CAUI level.
On the receive side, you can see whether each physical lane has locked onto the PRBS pattern, and the number of bit errors while in PRBS lock:
40/100G configuration
40/100G CAUI testing
Back to start
Overview... port configuration files
The file format used by the XenaManager for storing port configurations on the client is actually identical to the syntax used for scripting.
There is a simple line of ASCII text for each parameter, and they can be viewed in a normal editor:
The files can even be edited, and as long they conform to the scripting syntax they will be accepted by the tester.
The XenaManager itself does not inspect or check the content of the configuration files; they are passed transparently to and from the tester.
Port configuration files are not tied to any particular port, and can therefore be loaded into any port on any chassis.
However, each parameter of the configuration should be valid for the port it is being loaded into. Otherwise it will be flagged by the XenaManager:
In the above case it is quite harmless: a configuration was saved from a 10/100/1000 Mbps electrical port, and then loaded for a 100 Mbps optical port. The speed selection does not carry over in this case, but the rest of the configuration is accepted.
There is a similar file format for saving the configuration of all the ports of a test case to a single file.
Saving and loading
Test cases
Scripting
Back to start
Overview... test cases
Port configurations can be saved and loaded one at a time using the XenaManager.
It is also possible to save and load the configurations of all the ports of a testbed in a single operation. Such a compound configuration is called a test case:
There will typically be multiple test cases using a particular testbed, with a particular physical hook-up to run different test scenarios.
Like for individual port configurations, test cases use a simple text file format that exploits the scripting syntax:
A test case contains configurations for a specific collection of ports, namely those belonging to the current testbed when it was saved.
Before loading a test case all the ports must be reserved. This can be done as a single operation:
When a test case is loaded using the XenaManager, it makes a number of checks that those ports actually belong to the current testbed, are duly reserved, etc. As the parameters are being loaded into the various chassis the XenaManager produces a summary of the operation:
Testbeds
Reservation
Saving and loading
Port configuration files
Back to start
Overview... global control
Every port of the current testbed have separate buttons in the XenaManager for starting and stopping traffic, capture, and histograms, like:
This gives you maximum flexibility in controlling the operation of each tester.
However, when working with many ports it is inconvenient to have to start and stop them separately. Instead you can use the global buttons, located on a little panel on the "Global" tab of the content area:
The global panel is an ideal candidate for being pulled-out into its own little window.
Pressing the "START" button: stops any current traffic generation, clears all statistics, starts capture and histograms, and finally starts traffic generation.
Pressing the "STOP" button: stops traffic generation, and then stops capturing and histograms.
Pressing the "CLEAN" button: clears all statistics, and furthermore cleans out the list of observed test payload identifiers.
There can be a noticeable delay when using these buttons, since the XenaManager needs to communicate with all the chassis of the testbed, and wait for them to respond.
The global buttons are also useful even when you only use a single port. They automatically clear statistics and restart capture and histograms before starting traffic generation, and this is typically just what you want.
The global buttons by default affect all the ports of the testbed, but this can be turned off using the little check-marks next to each per-port button:
These check-marks are available for start/stop traffic, capture, and histograms, and for clearing transmit/receive statistics.
The setting of the check-marks is local to the XenaManager, and not stored on the chassis. They are therefore not inherited by any other client that connects to the chassis. They are saved along with the port parameters in the port configuration and test case files.
The global panel also shows the time elapsed since the "START" button was pressed, in the format 'days.hh:mm:ss', here just under five minutes:
You can make a timed test-run by entering the duration, in the case above one full day of 24 hours.
Traffic generation
Capturing
Histograms
Statistics
Testbeds
Test cases
Port configuration files
Content area
Pulling-out a panel
Back to start
Support
For support, email: support@xenanetworks.com
There are many resources available on the Xena Networks web-site: http://www.xenanetworks.com/html/resources.html.
Back to start