2.20.2   (2023-04-03)

Fixes

When the Scenario Heartbeat interval was set after Prepare() was executed on

an Endpoint, the new Scenario Heartbeat interval value was not propagated to the Endpoint.

The MeetingPoint could mark an Endpoint as "unavailable" when a test longer

than 1 minute was running.

This could lead to the ByteBlower GUI stopping a scenario while the test was

(rightfully) still running

2.20.0   (2023-02-27)

New features 

• The server now provides latency histograms over time when using the latency distribution trigger. This allows to have latency histograms per configured measurement interval.   
  This feature is useful when measuring the QeD performance of a specific flow. 

Enhancements 

• The TPID (EtherType) of a VLAN tag can now be configured through the API. 
• Faster filtering for traffic containing multiple VLAN tags. 
• The ByteBlower 2100 and ByteBlower 4100 server series did not support 4 stacked VLAN tags as the other series did.  Now all systems have the same limit. 
• The MeetingPoint will now automatically query the ByteBlower Endpoint for the test results when the Endpoint returns after a test. 
• The MeetingPoint needed up to 5 seconds for initial registration of an Endpoint.  The MeetingPoint now temporarily lowers the communication interval so this procedure finishes earlier. 

• The MeetingPoint tagged unverified ByteBlower Endpoint platforms as “Unsupported”.  The tag is renamed to “Unverified”, which means Excentis did not have tested this platform. 

Bugs fixed 

• The MeetingPoint stopped accepting API calls when an “Unavailable” ByteBlower Endpoint was addressed.  This did not only influence the calling test, but also effected other tests and users with “Available” Endpoints.  The only remedy for this was restarting the ByteBlower MeetingPoint service on the ByteBlower server. 

Changelog for 2.20.0 

New features 

• Adding latency histograms over time.  This can be used to visualise/verify the QeD performance of a specific application. 

Enhancements 

• Adding additional frameblasting interval statistics such as : 

• When was the first frame sent or received 
• When was time last frame sent or received 
• Minimum and maximum size of the frames received 

• Better latency measurements for cumulative snapshots.   
  The Endpoint now keeps track of the cumulative data itself instead of delegating this to the MeetingPoint. 

Fixes 

• Fixing crashes when a management/traffic interface was selected, but no IP address was available. 

A Guide to the Quick Self-Test Project

The purpose of this article is to help new users of the ByteBlower system to get started in an easy and efficient manner. When first setting up your ByteBlower, an example project is provided in order to gain familiarity with the GUI. In the following sections we will guide you step-by-step through the process of:

    1) Downloading the example project 'Quick Self-Test'.

    2) Running the 'Quick Self Test' by explaining how to connect the ports and giving a brief look at the various parameters that are used.

    3) Troubleshooting - What to do if the test does not work as expected.

By the end of this article we hope that you have had a successful first interaction with the ByteBlower GUI!

Step 1 - Downloading the Example Project 'Quick Self-Test'

https://setup.byteblower.com/ 

• In your case, this may have already been done. If not you can choose the appropriate installation manual.

• In this example, we have highlighted the 5100. Choose the correct manual for your ByeteBlower server.

• You will be taken to the page which explains how to install your new ByteBlower system. Once you have done that, scroll down to the following section.

Step 2 - Running the 'Quick Self-Test' Project

What is the 'Quick Self-Test and why is it useful? 

• The purpose of this test is to see if your ByteBlower server is working correctly. 

• The test uses a back-to-back wired connection between ports 1 and 2.

• This means that there are no other switches or intermediate devices involved in the test.

• If the test is set up correctly and no traffic is generated or received → We know there is a problem with the server itself.

• The test works by generating a frame blasting flow, which simulates traffic, and sending the it from one trunk port to the other.

This example test represents a downstream data flow from a server to a client device.

2.1 The Downloaded .bbp File

Open the downloaded .bbp file in the GUI. The first thing you will see is the display just below.

• The first red box is the 'Port' tab. This is where the user can add different ports that represent different parts of the network e.g. a server, a client, a PC, a smartphone etc. In this example project, two have already been created.
  

• The green box shows the IPv4 address as well as the default gateway for each port. In this example project, they are both provided.

• The last 2 red boxes are important! This indicates the ports that have been created and WHERE they are currently docked. You can see that the location is written in red which means they are NOT connected to a working server. You will also notice small red crosses which mean the ports are not connected.

              ⇒ The next step is to connect the ports correctly.

2.2 Connect the Ports to your ByteBlower Server

In this section we are going to create some ports which can represent a server and a client. These ports can be named as you wish. As you develop your testing capabilities, you can create many ports to represent many systems of interest.

We will then connect these ports representing a server and a client to the correct trunk ports on the ByteBlower server.

• Click 'New' and add the the IPv4 address of the ByteBlower server.  
  

• You can also edit the server that appears in the example file.
  

• It is possible to change the name of the ByteBlower server - in this demonstration it is Tutorial 3100.

• Once your ByteBlower server is visible, you will see two interfaces ⇒ trunk and nontrunk.

• Connect the traffic ports to 'Interface 1 - Trunk-1'

NOTE: Check you have connected 2 ports back-to-back (one port on top and one below). In this test port 1 is connected to port 2.

• Once this is completed, the 'Quick Self-Test' is ready to run!

• Just before we start the test, the next section will briefly look at the other tabs in the GUI that are used to create the test.

2.3 A Brief Overview of the Test Parameters

This section will give a brief explanation of some of the tabs in the GUI. This example project has already filled these in for you to make the test easy to run.

       1. Frame Tab - Creates a data frame

• For this test, we will use the default frame size → 1024
• Later, you can adapt the size of the frames as needed as well as manually add MAC and IP addresses.
• This is not recommended at this stage in order to run a basic test.

      2. Frame blasting - This creates the physical load to simulate traffic. 

• Frame blasting flows create a repeating flow of frames with a size determined in the previous step (1024)
• This frame blasting flow (UDP) is an easy way to simulate traffic.
• The physical load is the speed of the throughput. The speed in this demonstration is set at 838.4 kbps
• You can adapt this to match the speed you expect from your system.
• The frame rate and interval are automatically calculated based on your choice of the physical load.