Misc

This section describes the CLI for Xena’s stateful TGA Vulcan.

As an alternative to using the application VulcanManager, you can interact with the testers using XOA CLI for Vulcan. This also allows the tester to be controlled from a scripting environment, and be part of a larger automation environment.

Commands are logically grouped in a hierarchy. At the top level we have a Chassis. Currently there are two different Vulcan testers: VulcanBay and VulcanCompact. For VulcanBay and VulcanCompact, the entire chassis is considered one L47 Module, however in the future a chassis may have several Vulcan modules.

A Vulcan Module has several ports (currently between 1 and 12). Like on Valkyrie, each port must be reserved before it can be configured and traffic can be started, allowing multiple users to work with the Vulcan product at the same time.

In addition to ports a Vulcan Module contains a number of Packet Engines (PE) , which generates and handles the TCP traffic. As default each port is allocated one PE, however more PEs can be allocated to a Vulcan port increasing the performance on that port. Packet Engines are a shared resource between the Vulcan ports on a Vulcan module. Currently VulcanCompact contains 5 PEs and VulcanBay contains 2 groups of 14 PEs.

The Stream concept in Valkyrie has been replaced by Connection Groups (CG) in Vulcan. A CG specifies a number of TCP connections (1 to 2 million per PE). Several Connection Groups can be configured on a Port (currently up to 200).

A CG has a configured Load Profile, which defines the ramp-up start time along with the durations of the ramp-up, steady-state and ramp-down periods. A CG is configured with an Application Type and an Application Scenario. The Application Type defines the type of data transmitted by the TCP connections, and the Application Scenario defines the data flow between Servers and Clients.

By combining several Connection Groups on a port, it is possible to create a mixture of different traffic types and scenarios, and to create complex resulting load profiles.

Vulcan Port States

Vulcan test ports have seven states: OFF, PREPARE, PREPARE_RDY, PRERUN, PRERUN_RDY, RUNNING and STOPPED. Traffic is generated in the PRERUN and RUNNING states only, and configuration of parameters is only valid in state OFF except for a few runtime options.

Port traffic commands can be set with P4_TRAFFIC and port state queried by P4_STATE.

L47 Port States

Fig. 18 L47 Port State Diagram

  • OFF - default state. Entered from STOPPED or PREPARE on OFF command. This is the only state that allows configuration commands. P4_RESET is also considered a configuration command. Upon entering OFF state, some internal “house cleaning” is done. For example: freeing TCP Connections, clearing test specific counters etc.

  • PREPARE - this state is entered from state OFF on PREPARE command. Here internal data structures relevant for the test configuration are created. When done the state changes to PREPARE_RDY or PREPARE_FAIL and, a P4_STATE PREPARE_RDY or P4_STATE PREPARE_FAIL notification is sent to all users logged on to the chassis.

  • PREPARE_RDY - entered automatically after activities in PREPARE have completed successfully.

  • PREPARE_FAIL - entered automatically from PREPARE, if an error occurs. An error could for example be failure to load a configured replay_file.

  • PRERUN - entered from PREPARE_RDY on PRERUN command. If enabled, this is where ARP and NDP requests are sent. When done the state changes to PRERUN_RDY and a P4_STATE PRERUN_RDY notification is sent to all users logged on to the chassis.

  • PRERUN_RDY - entered automatically after activities in PRERUN have completed.

  • RUNNING - entered either from PREPARE_RDY or PRERUN_RDY on ON command. This is where TCP connections are established, payload is generated and connections are closed again.

  • STOPPING - entered from RUNNING, PRERUN_RDY or PRERUN on STOP command. Stops Rx/Tx traffic. In the STOPPING state, post-test data are calculated and captured packets are saved to files.

  • STOPPED - entered automatically after activities in STOPPING are complete. This is where we can read post-test statistics and extract captured packets.

CLI for Vulcan

CLI commands for Vulcan functionalities: