Traffic generators and testers are great tools for testing network functionality and performance.
But they are expensive – some prohibitively so!
Network Testers and QA engineers have always found workarounds and solutions to get more bang for their buck and work with limited resources.
One such ingenious solution is the Snake Test Topology to use just two traffic generator ports to test ALL 32 (or 48 or 96) ports of a switch at line rate.
This post explains another oldie but goodie solution to get more traffic generator and tester ports - using a switch as a port multiplexer to fan-out the traffic generator ports.
The concept is simple - send VLAN-tagged traffic from a single traffic generator port to a switch trunk port; the switch demultiplexes the traffic based on the VLAN tag (1 VLAN tag = 1 switch port) and sends it out of the corresponding access port after stripping the VLAN tag. The switch ports are connected to the various devices under test.
Here’s an example test topology using only 2 traffic generator ports to test a DSLAM AND 48 CPE devices - from back in the day.
This example can be easily extended to a PON or other FTTH deployment, even wireless APs and wifi routers! The concept remains just as applicable.
Using a switch to multiplex and demultiplex test traffic is an effective way to get more traffic generator and tester ports without having to buy more hardware.
Limitations
Like every workaround, this approach has its limitations though.
Results
- Packet drops within the switch may affect the results
- The single traffic generator port may not be able to break down the incoming aggregate traffic into individual VLANs to account for individual port stats
- You may need to fetch statistics from the switch ports
- Traffic passing through a switch introduces additional latency and potential jitter compared to direct connections
- You may not be able to get latency/jitter stats for individual ports - you may only get aggregate stats for the switch trunk port
Complexity
- While VLAN configuration on the switch is simple, it is still additional configuration compared to direct port connections
- Configuring multiple VLAN-tagged streams on a single traffic generator port makes it harder to manage and correlate which stream targets which port compared to using individual tester ports
- The switch must be performant enough to handle the aggregate traffic from all access VLAN ports and the trunk port in both directions
- Port related operations such as link state up/down, speed and duplex, etc. need to be done on the switch ports and not the traffic generator port - the traffic generator will be unaware of these changes
- Existing scripting/automation frameworks may need to be modified to support this approach
Debugging
- Troubleshooting becomes more complex when traffic is multiplexed through VLANs, making it harder to isolate issues
- Correlating the traffic streams to the switch access ports is more complex than using individual tester ports
Conclusion
The port fan-out using a switch is a good workaround to get more test ports - but it is not without its limitations.
One way to remove the limitations is to use affordable and cost-effective software traffic testers like Ostinato on COTS hardware with real full-featured traffic tester ports rather than having to work with an external switch and switch ports.
Finally, we would be remiss if we didn’t mention that although Ostinato is much more economical than the competition, it may still be too expensive for someone. If so, you can use this same approach to fan-out Ostinato traffic generator ports!