When you start running a test Scenario, the ByteBlower GUI/CLT tries to detect colliding Frames.
In this article, I'll explain what colliding Frames are, how they can corrupt your test results, and of course, how you can prevent or resolve these.

What are Colliding Frames ?

Each ByteBlower Port that is used as destination of a Flow, will contain filters to count the arriving frames, belonging to that specific Flow.
When your test involves multiple Flows, the filters will automatically be optimized, to make each one of them unique.
This way, we can be certain that only the Frames belonging to one specific Flow will be filtered out.
But when the frames used in different flows are identical or very similar, it is sometimes impossible to create unique filters.

At that point, it is no longer possible to determine which received Frame belongs to which Flow. 

As a result, the Frames belonging to multiple flows will be filtered by multiple destinations !
This typically results in negative loss. This means that you receive more packets than you have sent.

During the Scenario initialization, colliding Frames are detected, and a warning is generated.
Typically, a message will pop up to draw your attention, unless you switched this off in the Preferences.
In any case, the warning will be added at the bottom of the reports.

Possible solutions

The solution to make the Colliding Frames warning go away is to make all involved Frames unique.
There are several options to do this :

• By enabling the Unique Frame Modifier on Layer 4 of the Frames.  This option will make all Frames uniquely identifiable at all destinations.
• By changing the length of one of the Frames
• By changing one byte in the payload of one of the Frames
• For UDP frames without NAT discovery one can pick different UDP ports.