Valkyrie Knowledge Base

XenaLink Users Manual

XenaLink is a new application, which is currently under development by Xena Networks. It is a separate test application for automatically validating the transparency of a logical link such as a leased fiber link interconnecting two local area networks. XenaLink is able to determine which packet formats are able to pass unaltered through the link in terms of packet size and packet contents.

“Link” will be published in two versions:

  • XenaLink: This is a Windows application like Valkyrie2544 and ValkyrieManager, running as an independent GUI. This tool is not available yet and we have no firm deadline for its release.
  • ExcelLink: This application runs inside Microsoft Excel using Visual Basic scripts. Hence it is simply collection of spreadsheets inside a single Excel workbook. This tool is available now.

The documentation below is based on the current preliminary version of the ExcelLink application. “Using ExcelLink” is a quick getting started guide. If you are already familiar with Xena’s other Excel-based applications, you can skip this section. “Test Case Description” gives a more in-depth description of the individual test cases in the application.

Using ExcelLink

ExcelLink is used 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:

XenaLink

You then proceed through a few more sheets to fully define the test scenario, for instance setting the rate, size and test type parameters on the “TestCfg” sheet:

XenaLink

As you run each of the seven tests (Packet Size, VLAN, Ethertype/Length, Fault, Preamble, Protocol and Custom PCAP), they will provide detailed results for each test case:

XenaLink

To run multiple test cases in sequence, select which ones you would like to run in the “Preferences” sheet and press “RUN ALL” in one of the test case sheets.

Once the tests are concluded, a numerical summary is provided on the “Reports” sheet:

XenaLink

A full example of a report sheet can be downloaded here in PDF format:
Example Report.pdf

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.

Test Case Description

This section describes the basic function of the seven different test cases featured in ExcelLink.

Local/Remote Fault Test

This test is yet to be supported by the hardware.

The purpose of the Local/Remote Fault Test is to verify that Ethernet fault indications are passed transparently through the link. This is done by transmitting “Remote Fault” and “Local Fault” indication patterns into the link and checking that they are received unaltered on the other side.

Suggested settings can be seen in the Excel workbook under “TestCfg”.

Preamble Test (10G only)

This test is yet to be supported by the hardware.
The purpose of the “Preamble Test” is to verify that preamble patterns, which does not comply with the Ethernet standard is passed transparently over the link. This is to assure the correct function of devices which deliberately violate the Ethernet standard by modifying the preamble, e.g. to pass extra information between units in the preamble bit slots.

The test allows the user to transmit frames with non-standard preamble field through the link under test. Both the length and the contents of the field can be modified to mimic the preamble patterns, which are expected to run over the link.

Suggested settings can be seen in the Excel workbook under “TestCfg”.

Packet Size Test

Check to see if the DUT allows all packets sizes from min-to-max to pass. Min and max values are defined in “TestCfg”.

The receiving end check for packet loss, FCS errors and payload errors (DUT has changed payload and recalculated FCS).

If the test fails, XTT will attempt to determine which packet size intervals that cause the problem. The resolution (and hence the runtime of the search) can be defined in “TestCfg”.

The search will stop when the difference between the last successful and last unsuccessful packet size is equal or less than “Resolution” (defined in TestCfg).

VLAN Test

Check to see if the DUT allows all possible VLAN TCI values (within a user-defined range) to pass through (a VLAN tag consists of ”0x8100” (or 88A8 for the first Q-in-Q tag) + a 2 byte VLAN TCI followed by an EtherType field which points to the next protocol (IP/ARP/etc.):

XenaLink
Note that the ”CFI” field has been renamed to ”Drop Eligible (DE) in later versions of the IEEE 802.1Q protocol.

The test stream is composed of packets with either a single VLAN tag or a Q-in-Q (double VLAN) tag, where both VLAN tags are identical but have different EtherTypes (as per the standard). The VLAN TCI is incremented with each packet.

The user can select either a “Full Sweep” or “Custom” test. “Full Sweep” will run through all possible combinations of the 16-bit VLAN Tag. Tags which cause errors will be shown in hexadecimal format in the report. “Custom” will allow the user to specify a VLAN ID range to test as well as a static value for the PCP and DE fields.

The receiving end check for packet loss, FCS errors and payload errors (DUT has changed payload and recalculated FCS).

If the test fails, XTT will attempt to determine which intervals of TCI values that cause the problem. The resolution (and hence the runtime of the search) can be defined in “TestCfg”.

Ethernet Type/Length Field Test

Check to see if the DUT allows all possible Ethertype/Length field values (within a user-defined range) to pass through.

The test stream is composed of Ethernet packets where the Ethertype/Length field is incremented with each packet.

The receiving end check for packet loss, FCS errors and payload errors (DUT has changed payload and recalculated FCS).

If the test fails, XTT will attempt to determine which intervals of Ethertype/Length values that cause the problem. The resolution (and hence the runtime of the search) can be defined in “TestCfg”.


Protocol Test

The following protocols are tested:

  • Spanning Tree Protocol
  • Cisco Discovery Protocol
  • Cisco Unidirectional Link Detection
  • VLAN Trunking Protocol
  • 8023.ah OAM transparency
  • Pause Frames
  • BFD (Bi-directional Forwarding Detection)

One packet containing the tested protocol is sent to the receiver. At the receiver, the packet is captured and verified byte-by-byte with the (known) transmitted data. The receiving end furthermore checks for packet loss and FCS errors.

XTT reports “passed” or “failed” along with the type of failure (payload error, fcs error, packet loss).

Custom PCAP Test

This test is designed as an all-purpose tool to test protocols and packet formats, which are not included in the tests above. The test allows the user to transmit the contents of a custom .pcap file located in the same directory as XTT.

The user can define a packet range within the .pcap file to transmit. However, in case of large .pcap files it is recommended to trim away unwanted packets manually in Wireshark beforehand.

The receiving end will by default check for packet loss and FCS errors. Optionally (at the cost of longer runtime) the user can choose to perform a byte-by-byte check with the transmitted data to verify that the DUT has not altered the payload and recalculated the FCS.