Stream Properties#

This section describes the available stream properties for XenaManager.

../../_images/stream_properties_1.png
../../_images/stream_properties_2.png

Fig. 113 Stream Properties#

Common Stream Control#

This area contains port-level controls that affect all streams on that port. They are shown on the streams property page for the sake of convenience.

Traffic Control#

Table 39 Traffic Control#

Property

Explanation

Traffic Status

The current traffic status for the port (OFF: traffic is off, ON: traffic is on)

Traffic Control

This button enables you to either start or stop traffic on the port

Port TX Mode

This property determines the scheduling mode for outgoing traffic from the port, i.e. how multiple logical streams are merged onto one physical port. Refer to CLI command - P_TXMODE for further information.

Port Stop After

Stop port transmission after the specified number of packets are sent

Port Burst Period

Time in micro seconds from start of sending a group of bursts till start of sending next group of bursts

TX Time Limit#

Table 40 TX Time Limit#

Property

Explanation

Port TX Time Limit

The maximum time the port should transmit

Port TX Time Elapsed

The amount of time the port has been transmitting.

Main Properties#

This area contain all stream-level configuration properties, except those related to protocol header and modifier definitions.

Identification#

Table 41 Identification#

Property

Explanation

Port

The parent port name

Stream ID

The unique stream ID

Test Payload ID

The test payload ID (TID) carried in the Xena test payload area. This field can be empty if no TID value is needed.

Description

A user-modifiable description label for the stream

State

The stream enable state.

Transmission Profile#

Table 42 Transmission Profile#

Property

Explanation

Rate Fraction

The stream traffic rate expressed as a percentage of the effective rate for the port.

Packet Rate

The stream traffic rate expressed as packets per second.

Bit Rate L2

The stream traffic rate expressed as bits per second seen on Layer 2.

Bit Rate L1

The stream traffic rate expressed as bits per second seen on Layer 1.

Rate Cap

This command can be used to cap the rate for disabled streams. The button will only be enabled if the sum of the defined stream bandwidth actually exceeds the available port bandwidth.

Inter Packet Gap

The calculated mean inter-packet gap with the current TX profile settings. This denotes the space between the end of the preceding packet and the start of the following packet.

Seq.Packets

The number of sequential packets sent before switching to the next stream (packets). This property is only configurable when the Port TX Mode is set to Sequential.

Stop After

Stop stream transmission after the specified number of packets are sent. This value can be empty or zero, which means that the stream will continue to transmit until traffic is stopped at the port level. The Stop after function is not an option when Port TX Mode is set to Sequential.

Burst Size

The number of packets in each burst (packets). Valid range 0-500; in TX mode Burst **: 0-10000.

Burst Density

The density of the burst expressed as a percentage value between 0 and 100. A value of 100 means that the packets are packed tightly together, only spaced by the minimum inter-frame gap. A value of 0 means even, non-bursty, spacing. The exact spacing achieved depends on the other enabled streams of the port. Not used when TX port mode is Burst **

Inter Packet Gap **

Gap between packets in a burst. Only used when TX port mode is Burst

Inter Burst Gap **

Gap between this burst and burst in next stream. Only used when TX port mode is Burst

Inter Burst Gap

The calculated inter-burst gap with the current burst settings. This denotes the space between the end of the last packet in the preceding burst and the start of the first packet in the following burst.

Burst Signature

A graphical depiction of the current burst settings

Error Handling#

Table 43 Transmission Profile#

Property

Explanation

Insert Frame Checksum (FCS)

Control if a valid frame checksum is added to the stream packets. Default is enabled.

Error Injection

Specifies the type of error that is injected into the traffic stream. The following types of errors can be specified:

  • Frame Checksum Error: Injects an Ethernet FCS error.

  • Sequence Error: Injects a sequence error in the Xena Test Payload. This will result in a lost packet being counted. Only applicable if the stream has a TID.

  • Misordering Error: Injects a misordering error in the Xena Test Payload. Only applicable if the stream has a TID.

  • Payload Integrity Error: Injects an error by changing a byte in the payload.

  • Test Payload Error: Injects an error in the Xena Test Payload sequence forcing the packet to not being recognized at the receiving port as a Xena test packet. It will then be counted as a no-test-payload packet.

It is only possible to inject errors on a stream if traffic is active on the parent port.

Inject Error

Inject a single error of the specified type into the traffic stream. This option is only enabled when traffic is active on the parent port.

Packet Content#

Table 44 Packet Content#

Property

Explanation

Packet Size Type

The size distribution of the packets transmitted for the stream

Important

Read how to generate mixed packet size in MIX Weights.

Packet Auto Size

If selected XenaManager minimum packet size is auto adjusted so it equals the configured packet size in the stream.

Minimum Size

The lower limit of the packet size (if required by the size type)

Maximum Size

The upper limit of the packet size (if required by the size type)

Payload Type

The type of payload data used in the Xena payload section.

  • Incrementing 8-bits - means 00 01 02 03 04 05 … Provides built in payload integrity check for payload.

  • PRBS-31 - provides Pseudo Random Bit Sequence of 2^31-1 pattern. Payload integrity error detection requires non-zero Payload Checksum Offset in port properties of both TX and RX ports.

  • Random - provides Random bit Sequence pattern. Payload integrity error detection requires non-zero Payload Checksum Offset in port properties of both TX and RX ports.

  • Pattern - you can set your own custom pattern. Payload integrity error detection requires non-zero Payload Checksum Offset in port properties of both TX and RX ports.

  • Decrementing 8-bit: means FF FE FD FC FB FA … Payload integrity error detection requires non-zero Payload Checksum Offset in port properties of both TX and RX ports.

  • Incrementing 16-bit: means 00 00 00 01 00 02 00 03 00 04 00 05 … Payload integrity error detection requires non-zero Payload Checksum Offset in port properties of both TX and RX ports.

  • Decrementing 16-bit: means FF FF FF FE FF FD FF FC FF FB FF FA… Payload integrity error detection requires non-zero Payload Checksum Offset in port properties of both TX and RX ports.

Important

When using Incrementing 16-bit or Decrementing 16-bit, you need to check the option Payload Start From 0 to have the payload 00 00 00 01 00 02 00 03 00 04 00 05 … or FF FF FF FE FF FD FF FC FF FB FF FA….

Payload Pattern

The pattern of bytes to be repeated when the type is set to Pattern.

Payload Pattern Size

When choosing Pattern as Payload Type, it is possible to define the size of the repeated payload pattern part.

Ext. Payload Size

The size of the extended payload if this option has been enabled on the parent port. Refer to Freely Programmable Test Packets (Custom Data Fields) for details.

Connectivity Check#

Table 45 Connectivity Check#

Property

Explanation

IPv4 Gateway Address

The IPv4 gateway address used to resolve the DMAC address for the stream. Only valid if the stream contains an IPv4 protocol segment.

IPv6 Gateway Address

The IPv6 gateway address used to resolve the DMAC address for the stream. Only valid if the stream contains an IPv6 protocol segment.

Resolve Peer Address

Send an ARP or NDP request to the peer in order to resolve the MAC address. Only valid of an IPv4 or IPv6 segment has been defined with a valid Dest. IP address is defined.

Check IP Peer

Send a PING request to the peer in order to check the connectivity. Only valid of an IPv4 or IPv6 segment has been defined with a valid Dest. IP address is defined.

The Xena tester will set the Target IP Address in any ARP/NDP request sent from a Xena test port to a value in the following prioritized order:

  1. Stream gateway IP address for the IP version used by the stream if defined.

  2. Port gateway IP address for the IP version used by the stream if defined and stream Dest IP Address is not in same subnet as the port gateway (the legacy method).

  3. Stream Dest. IP Address

Packet Header Definition#

This section describes the Packet Header editor used by the stream configuration pages. The editor controls the definition the protocol header segments and the associated field modifiers.

Overview#

The defined protocol segments are shown in a Wireshark-like tree structure. All fields for a given segment header are shown as child rows under the segment row. Any modifiers defined on fields are shown as child rows under the field row.

../../_images/packet_header_def.png

Fig. 114 Protocol segment profile editor#

Tree Columns#

The treeview contains these columns:

Table 46 Packet Header Treeview#

Column

Explanation

Segment/Field Name

The name of the segment or field

M

Contains an icon that indicate if a collapsed segment or field row contains one or more modifiers.

Field Value

The actual field value in the common value representation for that field.

Named Values

Certain fields may get their value from a list of standardized or well-known named values. Instead of entering the value directly you can select the value from the dropdown list in this column.

Field Type Icons#

Each field row is prefixed with an icon indicating the value representation for the field. The following representations are used:

  • DEC: Decimal representation

  • BIN: Binary representation

  • HEX:Hexadecimal representation

  • MAC: A MAC address

  • IP4: An IPv4 address

  • IP6: An IPv6 address

Raw Hex Editor#

At the bottom of the treeview you will find a raw hex editor which allow you to inspect and optionally modify the raw hex data for the segment definitions. Any changes you make in the raw editor will be written to the chassis and the associated field value controls will be updated accordingly.

When you select a segment or a field the relevant parts in the hex editor will be highlighted. The hex editor will also underline the areas affected by any defined modifier.

The left part of the hex editor contains an address list and the right part show the current raw data decoded as printable ASCII.

Segment Headers#

Adding a Segment Header#

To add a new segment header to the existing definition press the Add Segment button in the in the command panel to the right. You will now be presented with a list of known protocol types in alphabetical order. You can select one or more types using the standard Windows Ctrl+Click or Shift+Click operations. When you are done press the OK button.

XenaManager will check if the total size of the configured segments exceeds maximum header size and minimum packet length, and if that is the case user will be presented with a message, which will also provide the option to increase “maximum header size and minimum packet length.

Note

If a segment is removed, the maximum header size and minimum packet length are not adjusted.

Moving a Segment Header#

With the exception of the first Ethernet segment you can move segment headers up or down in the list after you have added them. Select the segment you want to move and use either the Move Up or the Move Down button in the command panel to the right.

Any modifiers you have defined in segments affected by the move will be moved automatically.

Removing a Segment Header#

Select the segment you want to remove and use the Remove Segment button in the command panel to the right.

Any modifiers you have defined in the removed segment will also be removed automatically.

Import From PCAP File#

Instead of manually building the segment headers you can instead import the structure from a PCAP file. Note that this operation will replace any segments you may have added manually.

To import the segment structure from a PCAP file simply press the Import button in the command panel to the right and select a PCAP file on disk which contain the packet you want to import. The packets in the PCAP file will now be decoded and a list of the found packets will be shown. You should then select the packet you want to import and press the OK button.

The import function will use any trailing data in the packet as one or more custom data segments.

Note

You can download and try these PCAP sample files

Custom Segment Headers#

Custom Segments resemblances to Raw Segments, but they offer the ability to customize the header structure and assign custom names to fields. This feature, known as the Custom Segment feature, lets you craft your own protocol segment, typically represented as a JSON file. This customization significantly enhances usability and tailors the segment to your specific needs.

You can define your own custom segment as the steps described below:

  1. The new Custom segment files should be saved with .xdef extension.

  2. The content inside these .xdef files must use the JSON formatting.

  3. The .xdef files must be placed in C:\Users\<username>\Documents\Xena\XenaManager\SegmentDefs

  4. Click Add Custom Segment, and you will see the added segment.

Note

You can download and try these custom segment definitions.

../../_images/add_custom_segments.png

Fig. 115 Add Custom Segments#

The JSON format of .xdef file:

{
  "Name": "Custom Header",
  "Description": "Custom Header description",
  "SegmentType": 140,               //=> accepted values range: [128 to 191]. It's a unique key, so if more than one file with same SegmentType are detected, it'll load only the first detected one
  "ProtocolFields": [               //=> array of fields for the Custom Segment, you can define as many as you need but always following JSON formatting rules
    {
      "Name": "Custom field 1",
      "BitLength": 8,
      "DisplayType": "Decimal",     //=> accepted values: [Decimal, Binary, Hex, IpV4Address, IpV6Address, MacAddress, DisplayString]
      "DefaultValue": "0"   //=> accepted values can be defined in Decimal or Hex format. Can be separated by commas with no space (,) and each value corresponds to one byte.
    },
    {
      "Name": "Custom field 2",
      "BitLength": 4,
      "DisplayType": "Binary",
      "DefaultValue": "11"  //=> decimal “11” which will be displayed binary in UI as “1011”. Maximum value in this field would be “1111” (4 bits length / “15” decimal)
    },
    {
      "Name": "Custom field 3",
      "BitLength": 2,
      "DisplayType": "Hex",
      "DefaultValue": "0xF"         //=> Valkyrie Manager will skip this value and default it to 3 as 0xF is greater than max. possible value for a 2-bit field definition (range 0-3 decimal)
    },
    {
      "Name": "Custom field 4",
      "BitLength": 16,
      "DisplayType": "Hex",
      "DefaultValue": "0xFF, 0xFF"  //=> field defined as 16 bits, so we define 2-byte default values separated by comma and in Hex format, but we can also use Decimal format
    },
    {
      "Name": "Custom field 5",
      "BitLength": 48,
      "DisplayType": "DisplayString",
      "DefaultValue": "0x48,0x65,0x6c,0x6c,0x6f,0x00" //=> field defined as 6 bytes/characters, so to define default value Decimal or Hex format of ASCII values can be used and all 6 bytes needs to be defined
    } ,
    {
      "Name": "MAC Address",
      "BitLength": 48,              //=> MAC address field's length is always 48 / 6 bytes
      "DisplayType": "MacAddress",
      "DefaultValue": "0,0,0,0,0,0"
    },
    {
      "Name": "IPv4 Addr",
      "BitLength": 32,      //=> IPv4 address field's length is always 32 / 4 bytes
      "DisplayType": "IpV4Address",
      "DefaultValue": "0,0,0,0"
    },
    {
      "Name": "IPv6 Addr",
      "BitLength": 128,     //=> IPv6 address field's length is always 128 / 16 bytes
      "DisplayType": "IpV6Address",
      "DefaultValue": "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0"
    }
  ]
}

Setting Field Values#

You can change any field value by using the associated edit control in the Field Value column. For those fields that have a set of well-known values associated you can also choose one of these values from the dropdown list in the Named Values column.

Finally you may edit the content of the fields directly in the hex editor panel if you are so inclined.

Next-Protocol Type Fields#

Certain protocol segment types (such as Ethernet, VLAN and IP) contain fields that indicate the type of the next segment. The segment editor will attempt to set such fields to a correct value when you add, remove or move segments. You can however override the value afterwards if necessary.

Modifiers#

Modifiers are specified directly on the field hey are supposed to modify.

Adding Modifier#

To add a modifier select the field you want to modify and click the Add button in the Modifiers section in the command panel to the right. You will now be presented with a window allowing you to specify the properties for the modifier. Press the OK button when you are done.

The new modifier will be shown as a child row under the field row. The value in the Field Value column is a read-only string representation of the modifier settings.

Editing Modifier#

To edit the properties of an existing modifier select the modifier and click the Edit button in the Modifiers section in the command panel to the right.

Removing Modifier#

To remove a modifier select the modifier and click the Remove button in the Modifiers section in the command panel to the right.