Using a Multi-Chassis Set Up for Large-scale Application Traffic Simulation
by Todd DeverBy Todd Dever
A single BreakingPoint Storm CTM has some serious processing power: on its own, the device is capable of generating 40 Gbps of application traffic and 30 million simultaneous TCP connections. The recently announced BreakingPoint FireStorm CTM triples all of these numbers, but today we will focus solely on the BreakingPoint Storm CTM and demonstrate its ability to multiply its performance by a factor of five (Note: I illustrate this in a video below).
Configuring Five BreakingPoint Storm CTMs: Less Than Half an Hour
This project called for five fully loaded BreakingPoint Storm CTMs to be clustered together, with one system acting as the main unit and the other systems as subsystems. One of the beautiful things about using BreakingPoint Storm CTMs together in a multi-chassis configuration is that there is no need to stack or physically wire them together. All that’s needed is to have IP connectivity, then plug all of the testing interfaces into the same device under test (DUT). In fact, configuring and executing the multi-box simulation took less than 30 minutes. The longest part of that came with the initial out-of-box setup and simply cabling the BreakingPoint Storm CTMs to the device.
The initial configuration for the BreakingPoint Storm CTM units is done on an individual basis in order to assign an IP address and configure user accounts. In our case, the BreakingPoint Storm CTMs were plugged into the same network, and we used a common account on all units for ease of configuration. The system being tested was configured with sixteen 10GigE interfaces; we wired two interfaces per blade across eight blades and four BreakingPoint Storm CTM chassis for optimal performance. After verifying that the wiring and initial configuration were accurate, the multibox configuration was handled from the master system, with no direct configuration required on the subsystems.
Running a Multi-Chassis Simulation: As Simple as One
The master system is where you configure the simulation, along with your strike lists, DUT profiles, application profiles, Network Neighborhoods, and capture file. These elements get transferred to the subsystems when the multi-box simulation is executed. Additionally, you reserve all ports from the master system by using the IP and login that match each subsystem. (Note that it’s important that the port reservation numbers on all subsystems match the test configuration.) If a single Network Neighborhood is used, all subsystems can generate the same IP address ranges. However, for this particular process, we used specific Network Neighborhoods for each subsystem in order to create millions of unique IP addresses. We then saved the multi-box configurations on the master unit to make them available for future use or to other users.
To give you an idea of how easy this is to manage, here’s a screenshot of the Multi-box dashboard within the BreakingPoint Storm CTM:
As we all know, doing one simulation is almost never enough, and this test facility wanted to execute dozens of different simulations. You will want to do the same, as well as potentially do unique simulations in the future that incorporate new security attacks or different applications. A BreakingPoint multi-box simulation helps make this an easy process by providing the “Save As” feature. This allows you to apply changes to the simulation without having to re-create the entire multi-box scenario from scratch. In fact, in our multi-box simulation environment, each subsystem can run unique simulations using different profiles and Network Neighborhoods if required.
Single Reporting for Multi-Chassis Simulation
Perhaps one of the most pragmatic aspects of the way BreakingPoint does multi-box simulations is the single report that is generated. This comprehensive report contains all the results stored on the main system. Doing it this way saves you time and headaches. Just like you control the whole simulation from the main unit, you also see all the results from the main unit.
The results achieved for this test facility’s evaluation of the next-generation device were very telling. The device could handle about 65 Gbps of blended application traffic and just short of 14 million simultaneous TCP connections. The device could achieve 100 Gbps when only a single HTTP protocol with large GET and PUT payloads was used. And, finally, we saw the largest performance numbers, not surprisingly, when using bidirectional UDP protocol traffic, at which point we were witnessing 155 Gbps. This information is critical in determining whether the vendor’s claims are accurate and how these next-generation devices will work when deployed in your network.
By the way, this is the same point that Mike Murphy made a couple of weeks ago in his post about using the BreakingPoint FireStorm CTM to validate Cisco’s new ASA 5585 device: in the data sheet, Cisco publishes a maximum throughput number based off of simple UDP traffic, and another — much lower, but honest — number for multi-protocol traffic. That’s how vendors should do it, but too often they brag about the maximum number without putting it in context.
The huge capacity you get from a multi-chassis simulation becomes all the more useful as we see more of the newer high-performance pieces of network equipment coming out from device manufacturers. But, as I hope I’ve made clear in this post, performing these evaluations need not be a complicated process at all. We believe that executing simulations with our CTMs should be as straightforward and intuitive as possible, whether you’re using one chassis or five, so that you can accomplish what you need to as quickly and easily as possible.
Take a look at the following video, where I diagram this multi-box scenario and explain a little more about it:
blog comments powered by Disqus
