Welcome to the Excentis support portal. The requested article is not yet available to you. Please login with your credentials. If you don't have login credentials yet, please click here or contact us at support@excentis.com
Knowledge base

On this page you find the changelog for version 2.14 of the ByteBlower server. How to upgrade to this version can be read in the following article:

Server 2.14.0  (2021-12-07)


Introduction of the new port configuration.

  • This configuration matches the physical ByteBlower topology much closer and doesn't require any changes for the ByteBlower client.

  • The advantage is that each interface shown in the ByteBlower GUI's server view will correspond to a switch attached to the ByteBlower.

  • The strength of this new solution is well visible in daisy-chaining and multi-trunk setups. Find more examples in this article.

  • The upgrade will automatically update the config file to be compatible, but it is impossible to guess the correct physical layout. It is still necessary to manually configure your server to benefit from the new port configurations if you have a non-standard configuration. Please contact support.byteblower@excentis.com if you want help in doing this.


  • 5100 update system: The update could fail when trying to install a prerequisite which was already installed.


  • kernel update from 4.19.0-16 to 4.19.0-18 for the ByteBlower 5100 systems.
    This is routine maintenance of the OS. It has no impact on the traffic generation capabilities.


The ByteBlower server can be configured with mulitple switches and switch types yielding a flexible testing solution. This article will look at the different intefaces and daisy chaining possibilites.


Network Interfaces

The ByteBlower GUI and API offer two types of network interfaces for traffic generation ("traffic interfaces"):


  • Nontrunking interfaces are always found on the ByteBlower server. In general there are only few of this type but their bandwidth is not shared with any other interfaces.


  • Trunking interfaces are located on the ByteBlower switches. Unlike the nontrunk, systems can have many of this type. They tend to share connectors on the ByteBlower server but have the benefit of increasing port density and offering more flexibility in connectivity (e.g. NBASE-T)


Since ByteBlower Server v2.14 individual trunking interfaces can be grouped together very flexibly. The examples below show some of the possibilities.  Much more is possible of course! This feature is still in development (December 2021), contact us through support.byteblower@excentis.com to convert your system to a new layout.


This article lists the new possibilities, for systems up to 2.13 we recommend reading this article.


Daisy chain configurations

Within ByteBlower, a daisy-chain is any setup where several switches are connected in series starting from a single ByteBlower server connector. The most common variant is where are a 1Gbit switch is extended with a smaller NBASE-T capable switch (setup pages).




For older ByteBlower versions, all daisy-chained switches were grouped together in a single large trunk. As a user you were required to perform the arithmetic where each interface was located.


In the new version this has become much easier, the interfaces of each switch can easily be placed together in the same trunk.



This setup is in many ways the reverse of the above: multiple connectors on the server chassis are connected to the same switch for larger total throughput.



Prior to v2.14, the above setup resulted in 4 different trunks, with the interfaces split evenly across them. Users thus needed to calculate themselves where each interface was located.


The new version makes it easier. All interfaces belonging to the same switch can just be grouped together in a single trunk.


More possibilities

The above two examples show just the 2 most common options. What else is possible?


  • Pooling all DUTs of the same type in a single trunk. Regardless of where they are physically located

  • Creating many small trunks. For example, one per modem.

  • Splitting a shared ByteBlower System into different trunks, one for each team utilizing the setup.


The possibilities are limitless. Don’t hesitate to contact us if you don’t see your use-case mentioned. Together we’ll make it work!

GitHub Projects - Frame Blasting Modifiers

Following the previous article (Insert Link), we are going to explore some modifications to the frame and frameblasting flows. This will enable us to utilize more of the GUI's features; in particular the time and frame-size modifiers. These features create variations in the throughput which simulate non-uniform traffic flows.


We will look at 3 scenarios: 

  • Growing frame size - Frame increases size up to a maximum.

  • Random size

  • Bursty traffic - Frames sent in bursts  (1 second intervals).   


Each one of the tests will run vs a default frame for comparison purposes.


Let's go!



Part 1. Docking the Ports

When you open the .bbp file you will see the following displayed:


  • 2 ports configured with DHCP

  • Port 2 is NAT enabled


1.1 Connect the Ports to the Trunk Interface.


Port 1 and Port 2 are set are configured for DHCP so they should be docked onto trunk interfaces compatible with DHCP.

You will see that Port_2 has been NAT enabled but this is not strictly necessary.



  • In this example, trunk 1-3 and 1-4 are such interfaces.




Part 2. Frame Modifiers


In this part we will look at the different frames and frame blasting flows with their modifications. Frames can be modified in terms of their size (number of bytes) as well as adding a modifier at the level 4 layer. This can mean adding a payload offset. Another feature is changing the UDP source and destination ports at the level 4 layer (see below).

2.1 Frames


  • Two frames have been created with the default size of 1024 bytes. 

  • Going to the layer 4 setting we can see that Frame_1 and Frame_2 have different source and destination ports.




2.2 Frame Blasting Flows


In this step, we will look at the different frame blasting flows and how they transmit the data frames. The settings of the 'Frame Blasting' tab enable the user to adjust the thoughput speed as well as change the uniformity of the throughput. A frame blasting flow will take the frame defined in the previous step and repeatedly 'blast' it from source to destination.


In this example:


  • The growing size frame will produce a sawtooth throughput.

  • The random size frame modifier will generate random frame sizes between a minimum (60 bytes) and a maximum (1514 bytes).

  • The bursty traffic frame uses a time frame modifier to produce bursts of traffic containing 5000 frames with an interburst gap of 1.2 seconds.