Vulcan Connection Group

This module contains the Vulcan connection group commands that deal with configuration of TCP connections and are specific to Vulcan. The commands have the form P4G_<xxx> and require a module index id and a port index id, and a connection group index id.

A Connection Group (CG) is the basic building block when creating stateful traffic. A CG consists of a number of TCP connections - between one and millions. The CG has a role, which is either client or server. In order to create TCP connections between two ports on a Vulcan chassis, two matching CGs must be configured - one on each port - one configured as client and the other configured as server. The number of connections in a CG, is defined by the server range and the client range.

A server/client range is a number of TCP connection endpoints defined by a number of IP addresses and a number of TCP ports. A server/client range is configured by specifying a start IP address, a number of IP addresses, a start TCP port and a number of TCP addresses. The number of clients is the number of client IP addresses times the number of client TCP ports, and the same goes for the number of servers. The number of TCP connections in a CG is the number of clients times the number of servers, that is TCP connections are created from all clients in the CG to all servers in the CG.

Example:

A CG containing 100 clients on port 0 and 10 servers on port 1 can be configured the following way:

1/0 P4G_CREATE [0]
1/1 P4G_CREATE [0]
1/0 P4G_ROLE [0] CLIENT
1/1 P4G_ROLE [0] SERVER

1/0 P4G_CLIENT_RANGE [0] 10.0.1.1 10 5000 10
1/0 P4G_SERVER_RANGE [0] 10.0.2.1 10 80 1
1/1 P4G_CLIENT_RANGE [0] 10.0.1.1 10 5000 10
1/1 P4G_SERVER_RANGE [0] 10.0.2.1 10 80 1

Important

CG index must start from 0.

Now Port 0 contains 100 clients - 10 different TCP ports on 10 different IP addresses, and Port 1 contains 10 servers - 1 TCP port on 10 different IP addresses. When starting traffic on Port 0 and 1, 1000 TCP connections will be established - from all clients to all servers.

Note

When configuring a CG, both client AND server range must be configured on both CGs - that is, the server CG must also know the client range and vice versa.

The CG must be configured with a Load Profile, which is an envelope over the TCP connection’s lifetime. A connection in the CG goes through three phases. The Load Profile defines a start time and a duration of each of these phases. During the ramp-up phase connections are established at a rate defined by the number of connections divided by the ramp-up duration. During the steady-state phase connections may transmit and receive payload data, depending on the configuration of test application and test scenario for the CG. During the ramp-down phase connections are closed at a rate defined by the number of connections divided by the ramp-up duration, if they were not already closed as a result of the traffic scenario configured.

Example:

The 1000 connections configured above will be ramped up in 1 second - starting immediately - will live for 10 seconds, and will be ramped down in 2 seconds with the following configuration:

1/0 P4G_LP_TIME_SCALE [0] SECONDS
1/1 P4G_LP_TIME_SCALE [0] SECONDS

1/0 P4G_LP_SHAPE [0] 0 1 10 2
1/1 P4G_LP_SHAPE [0] 0 1 10 2

Note

Just like client and server range, both the client and server CG must be configured with the Load Profile.

Next the CG must be configured with a test application, which defines what type of traffic is transported in the TCP payload. Currently there are two kinds of test applications:

  • NONE means that no payload is sent on the TCP connections. This test application is suitable for a test, where the only purpose is to measure TCP connection open and close rates.

  • RAW means that the TCP connections transmit and receive user defined raw data. The contents of the raw TCP payload can be configured using the P4G_RAW_PAYLOAD command. Raw TCP payload can also be specified as random and incrementing data.

Using test application RAW, the CG must also be configured with a test scenario, which defines the data flow between the TCP client and server. Currently the following test scenarios can be configured: DOWNLOAD, UPLOAD, BOTH or ECHO.

Example:

The CG defined above is configured to transmit random payload data from the servers to the clients after the clients have transmitted (and the servers received) a download request, with the following commands:

1/0 P4G_TEST_APPLICATION [0] RAW
1/1 P4G_TEST_APPLICATION [0] RAW

1/0 P4G_RAW_TEST_SCENARIO [0] DOWNLOAD
1/1 P4G_RAW_TEST_SCENARIO [0] DOWNLOAD

1/0 P4G_RAW_HAS_DOWNLOAD_REQ [0] YES
1/1 P4G_RAW_HAS_DOWNLOAD_REQ [0] YES

1/0 P4G_RAW_PAYLOAD_TYPE [0] RANDOM
1/1 P4G_RAW_PAYLOAD_TYPE [0] RANDOM

By combining several CGs on a port, it is possible to create more complex traffic scenarios and more complex Load Profile shapes than the individual CG allows.